<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" 
     xmlns:content="http://purl.org/rss/1.0/modules/content/"
     xmlns:dc="http://purl.org/dc/elements/1.1/"
     xmlns:atom="http://www.w3.org/2005/Atom"
     xmlns:media="http://search.yahoo.com/mrss/">
  <channel>
    <title>Joshua Ayson&apos;s Blog</title>
    <link>https://joshuaayson.com</link>
    <description>Reflections on technology, creativity, and life</description>
    <language>en-us</language>
    <lastBuildDate>Wed, 10 Jun 2026 21:59:31 GMT</lastBuildDate>
    <atom:link href="https://joshuaayson.com/rss.xml" rel="self" type="application/rss+xml"/>
    <generator>Astro</generator>
    <copyright>Copyright 2026 Joshua Ayson</copyright>
        <item>
      <title>SAME NERVE: an Alan Watts mirror-song where pain and pleasure share one wire</title>
      <link>https://joshuaayson.com/2026/06/10/same-nerve/</link>
      <description>SAME NERVE is Song 08 in Out of Your Mind, the Napkin Films series built from the Alan Watts lectures. It is the one about pain and pleasure: the same nerve fires for both, and the suffering is the resistance, not the sensation. So the song is a literal mirror, the same melody and the same words harmonised first in C minor and then in C major, while a Plan 9 bunny walks the nerve like a wire and learns to ride the pulse it used to brace against. CC BY 4.0.</description>
      <content:encoded><![CDATA[Same nerve. Same fire. Two readings of one heat.

SAME NERVE is Song 08 in **Out of Your Mind**, the Napkin Films series built from
the Alan Watts lectures. This is the one about pain and pleasure. Watts points out
that the same nerve fires for both, and that the suffering is not in the sensation
but in the resistance to it. Brace against the wave and the grip is the cut, the
brace is the bruise. Accept it, and the identical signal arrives as warmth. In the
middle of the lecture he tells a true story: a man in an extreme situation, a bomb
falling toward him, who accepted, and woke up.

## A mirror, composed

The claim is structural, one signal with two readings, so the song is a literal
mirror. Verse A and verse B share the same melody and open on the same words,
harmonised first in C minor (pain) and then in C major (release). Nothing about
the tune changes. Only the harmony around it does, which is the entire lecture
rendered as a key change.

The bespoke device is the **nerve tone**: G, the dominant, held and re-struck
every single bar of the piece, a sustained violin and a celeste ping. G is a chord
tone of both C minor and C major, so one unchanging nerve sits inside every
harmony while the world recolours around it. The firing echoes an octave up and
ping-pongs left and right, one nerve heard from two sides. And the bridge drops to
a sustained open C with no third at all, neither minor nor major: the satori, the
signal before its reading. The score is an original ChipForge composition in a
romantic, Chopin-flavoured idiom, a singing right hand over a flowing left, with
an EDM kit that stays braced and gripping in the minor and opens in the release.

## The pulse made physical

The picture gives the idea a body. One nerve filament runs the width of the frame,
jagged hot red in the minor and a smooth gold sine in the major, and the Plan 9
bunny walks it like a wire across the entire film. Once a bar a pulse travels down
the line and passes underneath. In verse A it knocks the braced body, pressed
down, recoiling. In verse B the identical pulse is a lift the body rides. Same
input, two readings, visible in the body instead of explained in a caption.

At the satori the camera dives into the line and the world flips. The mirrored
reflection that has floated under the bunny all film becomes the upright figure,
the walker becomes the upside-down ghost, and a small constellation hiding in the
reflection world becomes its sky. The custom sound effects stem plays the same
trick in audio: the firing is a sub thump plus a zing that glides up an octave, in
key with the nerve tone, and physically pans left to right with the on-screen
pulse, jagged with grip creaks in the minor, the same gesture pure after the
satori.

## Voices

Der Gouverneur, a Bavarian philosopher governor voice, raps it in English and
German, every line locked to a whole number of beats at 96 BPM. The Plan 9 Glenda
bunny answers as the body itself: it grips, same heat, let it through, it's warm,
still me. The German motif runs through the whole song, Schmerz und Freude,
derselbe Nerv: pain and joy, the same nerve. The bomb story is spoken, not rapped,
over the open C.

## Made on a laptop

Stick-figure simple in Python and PIL, a beat-locked rap, a second character
voice, a ChipForge romantic piano EDM score, real drums and bass, a hand-built
sound effects stem. Generated locally. No GPU, no subscriptions, no stock footage.
Written, directed, composed, animated, voiced, and produced by Joshua Ayson with
AI, for Organic Arts LLC.

Watch it here: https://youtu.be/RiJCH3E0kzQ

## More from Napkin Films

- [Ego Is an Inch](/2026/06/06/ego-is-an-inch/), Song 07: the self you can never
  grab, Mussorgsky's Gnomus as grotesque EDM.
- [Attention Is the Loom](/2026/06/05/attention-is-the-loom/), Song 06: what you
  attend to becomes real, woven on an animated loom.
- [Ate the Menu](/2026/06/02/ate-the-menu/), Song 03: the map devoured the
  territory.
- [The Web](/2026/06/04/the-web/), Song 05: pull one thread and the whole thing
  moves.

## License

Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/). Remix it,
repost it, drop it into your own thing, credit "Napkin Films / Organic Arts LLC".
Engine code (Napkin Films, ChipForge) is GPL-3.0-or-later. ElevenLabs voice audio
is licensed content and is not redistributed. The music is an original ChipForge
composition in a romantic idiom; nothing was sampled and no melody was quoted from
any recording. The words are adapted and compressed from Alan Watts, Out of Your
Mind, not the original recordings.]]></content:encoded>
      <pubDate>Wed, 10 Jun 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/10/same-nerve/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/same-nerve-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Napkin Films, Vol. 2: five new ChipForge scores, and Vol. 1 remastered</title>
      <link>https://joshuaayson.com/2026/06/09/napkin-films-vol-2-bandcamp/</link>
      <description>Napkin Films, Vol. 2 is out on Bandcamp: five instrumental scores synthesized entirely in ChipForge from numpy arrays, plus a full remaster of Vol. 1 through the same engine. No samples. No recordings.</description>
      <content:encoded><![CDATA[[Listen on Bandcamp](https://organicartsllc.bandcamp.com/album/napkin-films-vol-2-instrumentals). Volume 2 is out: five instrumental scores from the [Napkin Films](/films/) universe, every sound synthesized in [ChipForge](/projects/) from numpy arrays. No samples. No recordings. No audio libraries. Math, rendered to sound.

This is the release I am most proud of so far, and not only because the music is better. The engine behind it grew up between Volume 1 and now, and once it had, I went back and remastered all five Volume 1 tracks through the same engine so the whole catalog sounds like one body of work.

## The five tracks

Four of these scores were written for [Napkin Films](/films/) shorts; the film came first, and this is the ChipForge music behind it, remastered to stand on its own. For each track there are three links: hear the song on Bandcamp, read the film's post here, and watch the film on YouTube.

1. **Throne Protocol**, 3:58, F minor at 145. Cold machine power; a dark synth-trap throne room. [Hear the song](https://organicartsllc.bandcamp.com/track/throne-protocol) · [Read the post](/2026/05/06/throne-protocol/) · [Watch the film](https://youtu.be/iEI8y8LeSik).
2. **Only Life**, 2:48, F minor at 100. Half-time trap, building a stage on top of the wound. [Hear the song](https://organicartsllc.bandcamp.com/track/only-life) · [Read the post](/2026/06/07/only-life/) · [Watch the film](https://youtu.be/Aqsrv686WvY).
3. **Disco Inferno**, 4:00, A major at 120. An ABBA-strings celebration with a four-on-the-floor heart. [Hear the song](https://organicartsllc.bandcamp.com/track/disco-inferno). Instrumental only, no film.
4. **Fault in the Code**, 3:04, B-flat minor at 120. Industrial; the flaw is the feature, distortion as honesty. [Hear the song](https://organicartsllc.bandcamp.com/track/fault-in-the-code) · [Read the post](/2026/06/08/fault-in-the-code/) · [Watch the film](https://youtu.be/CGvEq1ujrZk).
5. **Grand Tour**, 2:08, A minor at 122. A cinematic exhale, the long view from orbit. [Hear the song](https://organicartsllc.bandcamp.com/track/grand-tour) · [Read the post](/2026/06/01/the-grand-tour/) · [Watch the film](https://youtu.be/RxXN5KQrLmo).

Sixteen minutes of music. These are the beds, the instrumental scores. The rap and vocal versions stay with the films; these were built to stand on their own.

## What changed in the engine

Volume 1 shipped before ChipForge had a few things it has now. Volume 2 was built on all of them, and they are the reason it sounds the way it does.

**Hero voices.** ChipForge now carries a small set of signed-off instruments: a fat layered bass and three layered leads. Each one is six oscillator layers stacked together, with sub-octave chest weight, organum fifths and octave doublings, and a filter envelope that opens as the note holds. They are warm and big in a way the early presets were not. Three of these tracks (Throne Protocol, Only Life, Fault in the Code) were originally written as beds under a rap, so for the instrumental versions I put a melodic hero lead in the pocket the voice used to sit in. Each one now carries a tune on its own instead of leaving a hole where the vocal was.

**One master chain.** Every track on both volumes runs through a single mastering chain, parameterized by genre: de-mud the low end, lift the melody into presence, tame the harsh saw edges, anti-alias, then a gentle multiband, glue, and limiter, finished with a conservative normalize rather than a slammed one. Less limiting means less distortion. The practical result is that the songs sit at the same level and share the same tone, so an album plays like an album.

None of this is a plugin or a preset pack. The voices, the chain, the noise cleanup, all of it is Python computing samples into numpy arrays. The renders are deterministic: the same code produces the same record every time.

## Volume 1, remastered

[Plan 9, Napkin Films, Vol. 1](https://organicartsllc.bandcamp.com/album/plan-9-napkin-films-vol-1) went up in May. All five of its tracks have now been re-rendered through the current engine: the same hero voices, the same master chain, the same noise scrubbing. The compositions did not change. The sound did.

The Bandcamp album is the same record at the same link, and the audio under it is the remaster. If you already own it, the upgrade is yours. I wrote about that release when it first shipped: [Plan 9, Napkin Films, Vol. 1](/2026/05/25/plan-9-napkin-films-vol-1-bandcamp/).

## Listen

- The full catalog, with every track and its film, lives on [the music page](/music/).
- [Napkin Films, Vol. 2 (Instrumentals)](https://organicartsllc.bandcamp.com/album/napkin-films-vol-2-instrumentals) on Bandcamp.
- [Plan 9, Napkin Films, Vol. 1](https://organicartsllc.bandcamp.com/album/plan-9-napkin-films-vol-1) on Bandcamp, now remastered, and its [release post](/2026/05/25/plan-9-napkin-films-vol-1-bandcamp/).
- Everything from the studio: [organicartsllc.bandcamp.com](https://organicartsllc.bandcamp.com).
- Watch the films these scores belong to in the [full catalog](/films/).

Every sound on both volumes was computed in [ChipForge](/projects/), the Python engine that scores every Napkin Film. Buying an album supports the engine directly, and because the catalog is fully synthesized with no recordings or samples in the chain, the instrumentals are clean to license for film, video, and games. For commercial sync licensing, write to info@organicartsllc.com.]]></content:encoded>
      <pubDate>Tue, 09 Jun 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/09/napkin-films-vol-2-bandcamp/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/napkin-films-vol-2-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Breathe. Then Prompt.</title>
      <link>https://joshuaayson.com/2026/06/09/breathe-then-prompt/</link>
      <description>A freewriting companion to Working at the Frontier: breath as the one thing actually in my control, the anchor that keeps speed from becoming burnout near the forge. A small mantra for it: breathe, then prompt.</description>
      <content:encoded><![CDATA[View Original Handwritten Notes
[dflip id="breathe-then-prompt" source="/pdfs/breathe-then-prompt-2026-06-09.pdf"][/dflip]


Two thousand twenty-six. Tuesday, June ninth.

We are in the Decan of Sirius, the Dog Star. This is day 2 of the initiate phase. This decan demands that I plan and balance my time smartly. Both for this decan and the remaining thousand, give or take. The sun heats the surfaces to where they are too hot to lay on. A sensation that would have existed for many many thousands and millions of years. Weather. Heavy influencer, but out of my control. What is in my control is my breath. My mind goes in the way of that, but with practice I become aware of breath, more and more. And is breath that which I am. How can it not. Breath is there. I am here. No breath. And I would be gone. So it is breath which writes this.

It is the breath which offers me the peace. It is there, thus, that which outside is that which causes breath within to stir. Worth noticing. What if there is, within the human system, a desire to recurse on itself and map consciousness as system. There is also simplicity in the breath. When I become lost in my thoughts, it is the breath that unbinds and allows the free pen to flow across page and enjoy the sheer delight of being in space-time, taking some action, creating both experience and record, working to set aside anything layering on top, in between or in the middle, and returning to the breath when the structure becomes too weighty. The breath holds all.

<div class="image-container center">
  <img src="https://joshuaayson.com/images/free-writing/2026/06/breathe-then-prompt-01.webp" srcset="/images/free-writing/2026/06/breathe-then-prompt-01-480.webp 480w, /images/free-writing/2026/06/breathe-then-prompt-01-768.webp 768w, /images/free-writing/2026/06/breathe-then-prompt-01.webp 1024w" sizes="(max-width: 768px) 100vw, 768px" alt="An open notebook and fountain pen in cool dawn light, a faint breath of fog in the cold air" class="content-image" loading="lazy" />
</div>

It starts with the breath. Then you add, drink water, and make the bed. These come along and are the foundational components necessary to not burn up in the heat of a star like Sirius, and when operating at the forge in the heat of uncertainty, knowing that it is always possible to come back to steady measured awareness and breath and being, legible penmanship, and that being enough, and whatever, for whatever's sake.

<div class="image-container center">
  <img src="https://joshuaayson.com/images/free-writing/2026/06/breathe-then-prompt-02.webp" srcset="/images/free-writing/2026/06/breathe-then-prompt-02-480.webp 480w, /images/free-writing/2026/06/breathe-then-prompt-02-768.webp 768w, /images/free-writing/2026/06/breathe-then-prompt-02.webp 1024w" sizes="(max-width: 768px) 100vw, 768px" alt="Glowing orange forge coals in the dark with an iron bar heating among them" class="content-image" loading="lazy" />
</div>

At heart my dreams are that of a philosopher, and thus often work their way onto the page and wriggle their way sneakily out of my consciousness, when I'm simply trying to breathe and make nice scribbles and here comes some thought to ruin the experience and stop my breath entirely. And I realize this is the case most of the time, and the deep breath is the sign to do more breathing. Perhaps a new mantra:

Breathe. Then prompt. Then breathe. Breathe, breathe, breathe, breathe, breathe.

Even writing the word is enough to forget the act, and life is very sneaky, like that, and we have to watch all the tricks the senses play, transforming truth from experience into maps we may not have created. The software of existence is that which hardwires our hardware into the wetware, all driven by breath.

I keep writing this word, and it is a difficult one. Does it get the "e" at the end or not. In German it is Atem. The atom, with an E. I have to be careful when I write.

Sometimes I force myself to slow down and try the unfamiliar and really sit with constraint, and continue with the practice, working with breath and body, growing capability through the unfamiliar.

*A note: I wrote this last paragraph with my left hand. It took all my patience and breath to do.*]]></content:encoded>
      <pubDate>Tue, 09 Jun 2026 12:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/09/breathe-then-prompt/</guid>
      <category>free-writing</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/uploads/2026/06/2026-06-09-freewriting-lefthand.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>FAULT IN THE CODE: a study of Gasoline where the glitch is the glory</title>
      <link>https://joshuaayson.com/2026/06/08/fault-in-the-code/</link>
      <description>A Plan-9-flavored study of Halsey&apos;s &quot;Gasoline.&quot; OG Bobby Johnson spits, the cyborg bunny Plan 9 answers in tune, and a deep Alpine philosopher says the quiet part out loud: the bug is the feature.</description>
      <content:encoded><![CDATA[Watch on YouTube: [FAULT IN THE CODE](https://youtu.be/CGvEq1ujrZk). Licensed CC BY 4.0.

Halsey sings "I think there's a fault in my code." It is the cleanest line ever written about feeling manufactured. A self framed as a programming error. Then the song turns that into defiance.

I wanted to answer it from inside the machine. So I built a Plan 9 film around the same idea, and I let the bug be the feature.

## The thesis

The world keeps telling you that you were made wrong. Off the line with a crack in it. Stamped defective. Plan 9 is the patron saint of that feeling. The worst movie ever made, beloved exactly because it is flawed. The glorious B-movie defiance.

So the lyric and the music share one idea. The bed is industrial-electropop in B flat minor, one chord cell that never resolves, built so the engine's own glitches become the sound. The grit is the craft, not the accident. The glitch is the glory.

## A proper duo

OG Bobby Johnson carries the verses. Low, fast, slick, more gangsta than philosopher. He came off the line cracked and he made the defect a flex.

Plan 9, the cyborg bunny, is the counterweight. A higher voice answering in the gaps of the hook. Call and response. There's a fault in my code. A fault in the code. Never gonna patch it. Never patch it, no. The choruses build each time, more melodic, more swing.

And underneath, Der Gouverneur. A deep Alpine philosopher voice who only says the quiet part. Der Fehler ist das Wunder. The fault is the miracle. The bug is the feature.

## How it was tuned without losing the voice

The hard part was keeping it human. Recorded-style takes, beat-locked to the grid so the spit sits in the pocket, time-stretched without sounding sped up, and pitch-corrected with the formants preserved so each voice still sounds like itself. Tuned, but theirs. The whole vocal pipeline runs offline in ChipForge, the numpy synthesizer that also wrote the bed.

## The picture

Two stick-figure performers in a neon machine-room. The camera cuts to whoever is singing and pulls back to a two-shot when they trade, raining code and chromatic-aberration grit the whole way. The film wears the fault on purpose.

## The goodbye

At the end, Plan 9 signs off tongue in cheek and thanks Halsey for the spark. Then he says goodbye in Lenape, the language of the people who walked her home ground in central New Jersey first. Lapich knewel. The Lenape have no literal word for goodbye. It means "I will see you again."

## Made on a laptop

No GPU. No subscriptions. Animation in Python and PIL, audio in ChipForge, voices through ElevenLabs, glued together with FFmpeg.

## License

Film: CC BY 4.0. Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link CC BY 4.0. Engine code (Napkin Films, ChipForge) is GPL-3.0-or-later. ElevenLabs voice audio is licensed content and is not redistributed.

Halsey's "Gasoline" was studied for structure and spectral analysis only. No audio was sampled and no melody was quoted. This is an original work inspired by it.]]></content:encoded>
      <pubDate>Mon, 08 Jun 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/08/fault-in-the-code/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/fault-in-the-code-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Working at the Frontier: What It Actually Feels Like</title>
      <link>https://joshuaayson.com/2026/06/08/working-at-the-frontier/</link>
      <description>A field report from inside sustained agent-mode work: the heat behind the eyes, the way speed bends your sense of time, what it costs the body, and the practice that lets you build at the frontier anyway.</description>
      <content:encoded><![CDATA[View Original Handwritten Notes
[dflip id="working-at-the-frontier" source="/pdfs/working-at-the-frontier-2026-06-08.pdf"][/dflip]


There is a heat that comes with working alongside capable agents, and it is worth talking about, because almost nobody does. Much like a too-tight headband, or a beanie a size too small, it is a familiar kind of pressure, and it surfaces, eventually, as a real headache. When I notice it now I ask the plain questions first. Have I had enough water. When did I last take a break. I look out the window. I name something outside, a tree, a roofline, the color of the sky, and if the heat is still there I put on shoes and walk until it goes. The heat is information. It is a sign, the way a runner's blisters are a sign, that a good limit has been reached.

Because this is closer to training than to typing. You feed yourself a measured dose of hormesis, the useful kind of stress, the kind that builds cognitive holding capacity instead of breaking it, and you learn to work with the heat without standing in the fire so long that you burn out. You work near the forge where new ideas are born the way stars are born out of a nebula. Like all training, the worn synapses take their own time to come back. But the mind itself is resilient, and underused, and capable of far more than we tend to ask of it. What limits it, I think, is language, the narrow channel cognition has to pass through to become anything you can share. Once thoughts can travel faster, the thinking speeds up with them.

Both the speed and the ability to scale cognition change your perception of time. You get thrown into project-level wormholes, folding hours against the gracious estimates the tools hand you, until the only real limit becomes a question of how slow you are, and where the time went. All of it is in service of building something useful, and that is exactly where the huge missed opportunity lives, because most people take the speed and waste the build. So you develop the practice the way you would develop morning pages, by showing up to it. It is fine to vibe code, to try things, to let the agent run, and it should be encouraged. But as the system grows in complexity you add the appropriate layers in the same motion, the planning, the context, the guardrails, the structure, at the rate the complexity actually demands them.

<div class="image-container center">
  <img src="https://joshuaayson.com/images/essays/2026/06/age-of-agents-triangle.webp" srcset="/images/essays/2026/06/age-of-agents-triangle-480.webp 480w, /images/essays/2026/06/age-of-agents-triangle-768.webp 768w, /images/essays/2026/06/age-of-agents-triangle.webp 1024w" sizes="(max-width: 768px) 100vw, 768px" alt="Vintage sci-fi poster of an all-seeing eye inside a triangle labeled Plan, Observe, and Act, titled Age of Agents" class="content-image" loading="lazy" />
</div>

I have started calling this the age of agents, and I draw the same small figure in the margin every time. Plan. Observe. Act. It is not only the speed. The results that come out of scaling cognition under the right direction are astounding, given the calibre of the output. What changes underneath is the shape of the work itself. The way you think about the job moves from implementation to design, to orchestration, to efficiency, to anything and everything in between. It is devops applied to the whole of it.

That shift drives a real need, for technical ability and for familiarity, leaning harder than ever into architecture, into quality, into security, and into cost, all of it broken down continuously and accurately and kept attached to what it actually costs. Here is what I could not have written down eighteen months ago. This lets you leap-frog across domains. Once you have a general grasp of a new territory, its codex and its language, once the vocabulary is understood, there is great power waiting on the other side of it.

With the right context and the right systems you get to a high standard in a field in far less time than it used to take, and you start to find what I call the edges. The places where, with proper tools and the meta-capability of these models to abstract models and patterns, you can take some of the most sophisticated machinery there is and model the domains, the systems, the cognition itself, and bring coherence to complexity. The overwhelming becomes navigable. The illegible becomes legible. You draw the maps that let you work near the furnace, close to the source of the heat and the energy, and still keep enough of yourself in reserve to make sense of it all, or to hold what has to be held, and carry it.

Don't panic.]]></content:encoded>
      <pubDate>Mon, 08 Jun 2026 08:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/08/working-at-the-frontier/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/working-at-the-frontier.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>ONLY LIFE: a machine of coherent complexity, undone</title>
      <link>https://joshuaayson.com/2026/06/07/only-life/</link>
      <description>The opposing view of coherent complexity. A cold blue machine of rings and gears and towers cracks, collapses, and reveals a warm breathing core of life that blooms to fill the frame. F minor trap, a Bavarian philosopher voice, and a Sanskrit chant of darkness into light.</description>
      <content:encoded><![CDATA[Watch on YouTube: https://youtu.be/Aqsrv686WvY

CC BY 4.0 . 3:06 . coherent complexity, undone . F minor . 100 BPM half-time trap

We build a machine to make ourselves legible. A blueprint of the self. Every gear in a line. Every wire pulled tight. We name the fear and map the night and stack the reasons in a spire until the doubt resigns. Coherent and complex, and we swear it is ours.

ONLY LIFE is the opposing view. In the big moments, the last moments, all of that scaffolding is unnecessary. The cathedral shivers at the edge of the light, and the only thing true is the in and the out. The breath. The life.

## The idea

This started as the counter-argument to a thing I keep making, which is elaborate, legible systems. I wanted a film that builds the machine all the way up and then watches it crack, and finds that the simplest thing, the one in front of you the whole time, was the only real thing. So the picture is the argument. Not a metaphor laid over the song. The literal shape of the song.

## The picture is the argument

There are no characters in the body of the film. The whole frame is one idea, drawn in two colors.

A cold blue machine of coherent complexity sits in the center. Concentric data rings. Radial girders. Spinning gears. Wireframe towers over a blueprint grid. It is at full density in the first verse, humming, impressive, cold.

On every hook, pieces crack off and fall away as debris. At the bridge, on the line "let it fall," the whole structure collapses at once. And underneath it the whole time is a warm core that has been breathing through the gaps. As the machine falls, the core grows, and on the final hook it blooms into amber light and fills the frame.

Everything is procedural. Python, PIL, ffmpeg. No GPU, no stock footage. Two small craft notes I will keep:

The warm core is built as light, not paint. It is a blurred overlay of warm rings that gets added to the frame, screen style, instead of blended. The first version blended it and the center came out a muddy gray, because blending toward something that is black everywhere else just darkens the picture. Added, it reads as a light switching on. Which is the point.

And the cuts are locked to the real audio, not to a plan. Before I drew anything I ran the finished track through an envelope pass and pulled the actual section edges. The drop, the two hooks, the collapse, the bloom. The machine cracks on the music because it was timed to the music.

## The sound

The score is an original ChipForge composition, our own no-GPU music engine. F minor, 100 BPM, a half-time trap in the Post Malone lane. Der Gouverneur, an instant voice clone of a Bavarian speaker, raps the verses and sings the hook, intimate and a little tired, never shouted.

Under it runs a female Sanskrit chant: Asato maa sad gamaya, tamaso maa jyotir gamaya. Lead me from the unreal to the real, from darkness to light. It is the film said plainly. The cold machine is the unreal and the dark. The bloom is the real and the light. The chant is autotuned to the song's own key so it sits inside the harmony, it sings instead of drones, and it clears away before the bridge so the exposed vocal owns the last third. The mantra finishes as the light arrives.

## The bookends

A space and navigation cold-open, a gyro ring and a reticle and a swept course over a starfield, set to the Stranger Things alien chirp. And at the end a Plan 9 bunny dances over the bloom and signs off in a new tongue, Hindi this time: phir milenge, yaatri. We will meet again, traveler.

## More from Napkin Films

This is a companion piece to the Cartographer of Complexity work, the other side of the same coin: [Making Complexity Legible](/2026/06/06/making-complexity-legible/) argues for the map, and this one argues for putting the map down. The procedural-light and additive-bloom techniques grew out of [The Grand Tour](/2026/06/01/the-grand-tour/). The voice is the same Bavarian clone that carries the Out of Your Mind series, like [Ceramic](/2026/05/24/ceramic/).

See everything at [the films page](/films/).

## License

This film is licensed CC BY 4.0 (Creative Commons Attribution 4.0 International). Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link CC BY 4.0: https://creativecommons.org/licenses/by/4.0/

Engine code (Napkin Films, ChipForge) is licensed GPL-3.0-or-later. The music is an original ChipForge composition. ElevenLabs voice audio is licensed content and is not redistributed outside of this film.]]></content:encoded>
      <pubDate>Sun, 07 Jun 2026 19:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/07/only-life/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/only-life-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Making Complexity Legible: a beat-locked spit-rap on charting complex systems</title>
      <link>https://joshuaayson.com/2026/06/06/making-complexity-legible/</link>
      <description>Making Complexity Legible is Case I of The Cartographer of Complexity, a new Napkin Films series about Making Complexity Visible. The idea: you cannot make a complex system simple without deleting what made it work, so you do not shrink the sea, you learn to read it. A tidal-EDM spit-rap, Plan 9 and OG Bobby trading bars over recomposed Telemann, with a cartographer bunny who roams a sea that brightens as it becomes legible. CC BY 4.0.</description>
      <content:encoded><![CDATA[Chart the ocean. Don't shrink it.

**Making Complexity Legible** is Case I of **The Cartographer of Complexity**, a new
Napkin Films series about **Making Complexity Visible**. This first one is about
legibility. You cannot make a genuinely complex system simple without deleting the
very things that made it work. The accidental clutter, sure, cut that. But the
essential complexity *is* the system. So the move is not to shrink the sea. It is to
become big enough, and your map rich enough, to read the whole thing at once.
Requisite variety: the chart gets as rich as the water. Not smaller. Clearer.

## Why the music is the idea

The theme is the tide you cannot drain, so the sound is a tidal EDM bed in C minor,
recomposed from Telemann's water music with ChipForge, my own no-GPU, no-samples
engine: a swelling sub that ebbs and flows, a glassy water arp, a clean four-on-floor
with a kick-keyed sidechain pump, and a register-voiced grand piano. The drop is the
"legibility lock," where everything snaps to a unison hook over a big swelling sub:
the chart locking onto the sea without shrinking it.

The rap is a dialogue. **Plan 9**, the Cartographer, carries the melody. **OG Bobby
Johnson** trades baritone bars, the street-realist grounding the vision: simple is a
sticker, legible pays the rent. An Egyptian ritual voice plants the names in the
gaps, Cartographer of Complexity, Making Complexity Visible, so the ideas lodge and
become something you can look up later.

## The picture

Stick-figure simple. A cartographer bunny that roams the frame and steps to the beat,
charting a dark sea that brightens as it becomes legible. Overhead, a building chart
of the heavens: parallels and meridians converging to a pole, a spinning compass
rose, a constellation of data nodes, complexity made visible. The bookends are the
series' own: a Stranger-Things-style chirp and an EDM pad on a napkin card to open,
and at the close Plan 9 takes a tongue-in-cheek bow with a little dragon doodle and
signs off in the cartographer's dead languages: Vale, viator. Hic sunt dracones. Co'o.

## Made on a laptop

Python and PIL at 854x480, 12fps. A beat-locked spit-rap, two rapping characters plus
a ritual voice, a ChipForge Telemann recomposition, real drums and bass. Generated
locally. No GPU, no subscriptions, no stock footage. Written, directed, composed,
animated, voiced, and produced by Joshua Ayson with AI, for Organic Arts LLC.

Watch it here: https://youtu.be/sYCdoxt-ZhY

Licensed CC BY 4.0. The music is an original ChipForge arrangement inspired by the
public domain works of Georg Philipp Telemann; the source was studied for structure
only, nothing was sampled.]]></content:encoded>
      <pubDate>Sun, 07 Jun 2026 03:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/06/making-complexity-legible/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/making-complexity-legible-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>The AI-Assisted Engineering HOWTO</title>
      <link>https://joshuaayson.com/2026/06/06/ai-assisted-engineering-howto/</link>
      <description>A practical, plain-spoken manual for building software with an AI agent: the setup, the loop, context management, and verified Claude Code and Copilot commands. Written like the old Linux HOWTOs, by someone who runs it daily.</description>
      <content:encoded><![CDATA[*Revision 1.1, June 2026. This is a HOWTO in the old sense: a plain manual you can read top to bottom and then go do the thing. I grew up on the Linux Documentation Project, learning the internet one HOWTO at a time. I wanted to write one for years. This is that document, for the skill I use most now. It has high-level tips and it has commands you can paste. Come back to it.*

## 0. Introduction

AI-assisted engineering is building software by directing an AI agent instead of typing most of the code yourself. Done well, it is the biggest change to how I work in fifteen years. Done badly, it produces confident garbage faster than you can read it.

This manual is the difference between the two. It is the setup, the loop, the commands, and the failure modes, written for an engineer who has used a chat assistant a few times and now wants to work this way for real, on a codebase that matters.

I run this with two tools and two models. Claude Code in the terminal. GitHub Copilot agent mode in VS Code. Sonnet for most of it, Opus when the thinking gets hard. The method outlives any one tool, but I am going to be specific, because a HOWTO with no commands in it is just an opinion.

### 0.1 Who this is for

You write or maintain real software. You have opened an AI chat window, pasted some code, and gotten useful answers back. You suspect there is more to it. There is. You do not need to be an expert. You do need to stay responsible for the output.

### 0.2 What this is not

This is not vibe coding, the practice of prompting and hoping and shipping whatever falls out. If you want that line drawn clearly, read [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/) first, then come back. It is also not a magic-prompt collection. There is no incantation. There is a method.

## 1. What you need before you start

A short list. The rest of the document assumes you have it.

1. A real project under version control. Git, committed, clean working tree. This is your safety net and it is not optional. If you cannot get back to a known-good state in one command, fix that first.
2. A test suite, even a thin one. The agent will run it. Tests are how the machine checks its own work so you do not have to read every line by hand.
3. At least one agent with hands. Claude Code in the terminal, or Copilot agent mode in VS Code, or both. A chat box you paste into is the training-wheels version. You want the version that can read the repo, edit files, and run commands.
4. A few minutes to write down how your project works. That file beats any prompt trick, and section 4 is about building it.

## 2. The mental model: you stopped typing

The hardest part of this is not technical. You have to stop thinking of yourself as the person who writes the code.

For most of your career the bottleneck was your hands: how fast you turned an idea into correct syntax. AI moved that bottleneck. The cost of producing code fell to almost nothing. What did not get cheaper is deciding what to build and confirming it is right. That is where your whole job lives now. I wrote about the shape of this in [Agent Mode Changes the Shape of Thought](/2026/06/05/agent-mode-changes-the-shape-of-thought/), and about its hidden bill in [The Cognitive Cost of Modern Software Engineering](/2026/06/05/the-cognitive-cost-of-modern-software-engineering/). You become a director, not a typist. Direction is harder than it sounds.

Here is what that looks like at my desk. This is my own setup, on my own time. On my Organic Arts LLC projects and websites, where I set the rules, I run four to eight Claude Code terminals at once, each on a different task, with VS Code open beside them for review: reading the code and the markdown, making small tweaks by hand, stepping through git compares before anything gets committed. The terminals do the building. VS Code is where I look before I trust. My day job is its own world with its own approved tooling, and I am thankful to work somewhere that actively encourages AI-assisted engineering; there the setup is tighter and editor-first. The number of windows is not the point. The work is parallel now, and your job is to keep the parallel work coherent.

Hold that picture. Every tip below is really about protecting the two things only you can do, deciding and verifying, and handing the rest to the machine.

## 3. The two tools I use

Pick a tool with real repository access and learn it well. Two windows beat ten you half-know. Here is the stack I actually run.

### 3.1 Claude Code, in the terminal

This is where most of my building happens. You start it in the project directory:

```bash
claude                      # start an interactive session in the current repo
claude --model sonnet       # start on Sonnet (fast, my default)
claude --model opus         # start on Opus (deeper reasoning, harder problems)
```

Inside the session you talk to it in plain language and it does the work: reads files, writes the change across the codebase, runs the tests, reports back. You switch models mid-session when a task gets hard:

```text
/model opus                 # switch this session to Opus
/model sonnet               # switch back
```

`Shift+Tab` cycles the permission mode: ask-every-time, auto-accept edits, and plan mode (read-only, where it proposes a plan before touching anything). I live in ask-every-time for real work and plan mode when I am still deciding what to do. `Esc` interrupts it the moment it heads the wrong way. Do not wait politely for a bad run to finish.

### 3.2 Copilot agent mode, in VS Code

When I am already in the editor, or my setup is constrained, I use Copilot agent mode. Open the Copilot chat panel, switch it to Agent, and pick the model from the selector. The same two names are there: Claude Sonnet for daily work, Claude Opus when the problem is gnarly. Agent mode does what the terminal does, multi-file edits and a test loop, with the diff right there in the editor where you read it.

### 3.3 When I reach for which

The terminal wins when I want many things happening at once, or I am scripting, or the job is large. The editor wins when the change is small and visual and I want to eyeball the diff as it shows up in the tree. Neither is the "real" one. They run the same loop. Use the one whose friction is lower for the task in front of you.

## 4. Set up your workspace: the memory file

Before you ask the agent to do anything, give it a place to stand.

The single most useful thing you can do is write a project memory file: a document the agent reads every session that tells it how this project works. Each tool reads its own, and this is the part people get wrong, so be clear about it:

- **Claude Code** reads `CLAUDE.md` at the repo root. It also reads a personal one at `~/.claude/CLAUDE.md` for your cross-project preferences, and nested `CLAUDE.md` files deeper in the tree when it works in those folders.
- **Copilot agent mode** reads `.github/copilot-instructions.md` at the repo root.

They are not either-or. They are additional. If you use both tools, you keep both files, and you keep them saying the same thing. This repo carries both. Same content, two front doors.

Claude Code can write you a starting draft from the code itself:

```text
/init                       # generate a starter CLAUDE.md from the codebase
/memory                     # see which memory files are loaded right now
```

Put in the file what you would otherwise repeat out loud every session:

- What the project is, and how it is built, tested, and run.
- The conventions you actually enforce, in your own words.
- The parts that are dangerous to touch, and the rule for touching them.
- The mistakes the agent already made, so it stops making them.

Keep it lean. A long memory file is a memory file the agent skims and you stop maintaining; aim for something you would actually read. When it grows, split the detail into smaller files and pull them in with `@path` imports:

```markdown
See @docs/architecture.md for the system layout.
Testing rules live in @docs/testing.md.
```

This file turns your standing intent into something permanent. You write your standards once and they apply forever, instead of re-explaining them in every prompt. A good memory file is worth more than any clever phrasing, because it removes the need for clever phrasing. Appendix A has a starter you can copy into either file.

## 5. The core loop

Everything else is one loop, run over and over: **specify, delegate, verify, record.** I run it every day and wrote it up in full in [An AI Agent Workflow for Software Engineers That Actually Holds Up](/2026/06/02/ai-agent-workflow-for-software-engineers/). The working summary:

**Specify.** Get clear on what you want before you type a prompt. For anything past a trivial fix, write the intent down: the outcome, the constraints, what is non-negotiable. Vague in, vague out.

**Delegate.** Hand over the task, not the keystrokes. "Add rate limiting to the payments endpoint and update the tests" is a task. Let the agent read the code, make the change, and run the suite. Do not micromanage the implementation. You set the destination; it drives.

**Verify.** Read the diff. Run the tests. Check the real behavior, not just that a command exited zero. People skip this step and it is the one that matters most, so it has its own section below.

**Record.** When you make a real decision, write down why. I work off architecture decision records a lot of the time, one short ADR per real choice, plus a journal note for myself. An ADR pays off twice: it records why you did something, and next time it specifies the work, because a clear decision is already most of a clear prompt.

The loop holds because the first and third moves are exactly the moves an agent cannot make for you. That is the point of the whole method.

## 6. Context and token management

The agent only knows what is in its context window: the running record of your conversation, the files it has read, the test output it has seen. The window is large but not infinite, and a stuffed, stale window makes the agent dumber. Managing it is a real skill, so treat it like one.

Two commands do most of the work:

```text
/context                    # see what is filling the window right now
/clear                      # wipe the conversation, keep the project memory file
/compact                    # summarize the conversation so far and keep going
```

Use `/clear` between unrelated tasks. A fresh window for a new job is faster and sharper than one dragging an hour of irrelevant history. Use `/compact` when one long task has filled the window but you still need its thread; it keeps the gist and drops the noise. Check `/context` when answers start drifting; a full window is often the reason.

Model choice is the other lever. Sonnet is fast and cheap and handles most engineering work, so it is my default and I leave it there. I move to Opus when a task needs real reasoning: a thorny architecture decision, a bug that has survived two attempts, a plan with many moving parts. Then I move back. Running everything on the heavier model is slower and costs more without making the easy work any better. Match the model to the difficulty, not to your mood.

There is a sharper reason to care about all of this: tokens. The deeper you get, the more you feel it, especially as you near a plan limit or you are paying by the token. The skill that compounds is accomplishing more with fewer tokens, and it is worth treating as a craft of its own. A tight task that points the agent at the three files that matter costs a fraction of a vague one that makes it read half the repo just to orient itself. Clear between tasks so you are not paying to carry dead history. Keep the memory file short. Send big searches out as a subagent so the long output stays out of your main window. Reach for Sonnet first and save Opus for where the reasoning earns its higher price. Doing more with less is not a constraint here. It is the game.

## 7. Tips and tricks

The part I would have read first. Each of these I learned by getting it wrong.

1. **Commit before any big agent run.** A clean checkpoint means a bad run costs you a `git reset --hard`, not an afternoon. Treat the working tree as scratch paper the agent writes on.

2. **Work in small, verifiable units.** One coherent change at a time. A pile of changes you cannot review is a pile you cannot trust, however good it looks.

3. **Make the agent run the tests itself.** Do not run them and report back. Wire it so it sees the failures directly and iterates. Closing that loop is most of the magic.

4. **Green is necessary, not sufficient.** AI-generated code can pass every test and still be wrong, because the test never covered the thing that breaks. Passing tests buy confidence, not certainty.

5. **Verify behavior, not exit codes.** A command that exits zero did what it was told, which is not the same as what you wanted. For anything that touches the real world, look at the real world.

6. **Give it the error, not your summary of the error.** Paste the actual stack trace, the actual failing test, the actual log line. The agent is good with raw evidence and bad with your paraphrase.

7. **Fence the dangerous areas in writing.** If code must not change without care, say so in the memory file, not in your head. The agent honors written rules. It cannot read your worries.

8. **Say a correction once, in the memory file.** If you find yourself fixing the same thing twice, that fix belongs in the file, permanently.

9. **When it goes in circles, stop and re-specify.** An agent stuck in a loop is almost always an agent you under-specified. The fix is upstream, in what you asked, not in asking again louder.

## 8. Commands and hacks worth knowing

These are the moves that compound once you are past the basics. All of them are part of how I run a normal day.

**Headless mode, for scripting.** Outside a session, `-p` runs one prompt and exits. Good in scripts, git hooks, and CI:

```bash
claude -p "summarize the changes in the last commit"
cat error.log | claude -p "what is the root cause here?"
```

**Pick up where you left off.** A session is not gone when you close it:

```bash
claude --continue           # resume the most recent session in this repo
claude --resume             # choose from a list of past sessions
```

**Run agents in parallel without collisions.** This is how the four-to-eight-terminals setup actually works. Each agent gets its own git worktree, a separate checkout of the same repo on its own branch, so two agents editing at once never step on each other:

```bash
git worktree add ../proj-auth     -b feature-auth
git worktree add ../proj-logging  -b fix-logging
# open a Claude Code session in each directory; they cannot collide
git worktree list
git worktree remove ../proj-auth  # clean up when the branch is merged
```

**Teach it a repeatable job once.** A custom slash command is a markdown file of instructions you invoke by name. Drop it in `.claude/commands/` in the repo (or `~/.claude/commands/` for all your projects):

```bash
# .claude/commands/ship.md  ->  invoked as  /ship
# put your standard pre-deploy steps in that file in plain language
```

After that, `/ship` runs your checklist the same way every time. This is the lock-it-down move from the next section, made concrete.

## 9. Lock it down, or leave it open

There are two modes of working this way and you need both.

Sometimes I want the creativity of not locking things down. I give the agent room, leave the constraints loose, and let it surprise me. I try to encourage artistry in the outcome and in the system itself, not just correctness. This is the same instinct I bring to freewriting, the practice I call consciousness mining: keep the prompt loose, stay honest, get the ego out of the way, so something I did not plan has room to surface. You are fishing, and you want a wide net. A tight spec here kills the thing you were reaching for.

Other times I build for repetition and lock it down hard. A clear ADR. A strict memory file. Fences around the dangerous code. A custom slash command so the steps never drift. A task specified so tightly there is one reasonable result. That is the mode for work that has to be right and has to be the same every time.

The skill is knowing which one you are in. Leave a production change loose and you ship a subtle bug. Lock down an exploration and you kill the surprise you were after. Decide on purpose, at the start, which mode the task is, and do not drift between them by accident.

## 10. Common failure modes and how to fix them

Symptom, then cause, then fix.

**The output looks right and is subtly wrong.** Cause: you verified the build, not the behavior. Fix: exercise the actual feature. I once moved a site to a private origin; the change was correct except the new origin did not serve directory index files, so every subpage would have broken. The build was green. I caught it by loading a real page, not by trusting the log.

**It keeps reintroducing a mistake you fixed.** Cause: the correction lives in your memory, not the project's. Fix: write the rule into the memory file so it survives the session.

**Its answers start drifting and getting vague.** Cause: the context window is full of stale history. Fix: `/clear` for a new task, or `/compact` to keep the thread but drop the noise. Check `/context` when in doubt.

**It changed something you did not ask it to.** Cause: the task was broader than you thought, or the danger zone was not fenced. Fix: narrow the task, mark the protected areas in writing, reset to your last commit.

**It is slow and you want to just write it yourself.** Cause: the task is small enough that specifying it costs more than doing it. Fix: do the small ones yourself. The loop earns its keep on tasks big enough that direction beats typing. Not everything should be delegated.

**You shipped fast and now you do not understand your own system.** Cause: you skipped the record step, and speed without memory is debt. Fix: slow down on the decisions, write them down, read the diffs you waved through. The cognitive bill is real and it comes due.

## 11. Frequently asked questions

**Claude Code or Copilot agent mode?** I use both. Terminal for parallel and large work, the editor for small visual changes. They run the same loop. My longer comparison for engineering work is in [Claude vs Copilot for DevOps](/2026/06/02/claude-vs-copilot-for-devops/).

**Sonnet or Opus?** Sonnet for almost everything; it is fast and it is enough. Opus for the hard reasoning: thorny architecture, a bug that survived two attempts, a plan with many parts. Switch with `/model`, then switch back.

**CLAUDE.md or copilot-instructions.md?** Both, if you use both tools. Claude Code reads `CLAUDE.md`; Copilot agent mode reads `.github/copilot-instructions.md`. Keep both, keep them in sync. They are additional, not a choice.

**Is this just vibe coding with extra steps?** No, and the difference is the whole thing. Vibe coding skips specify and verify. This method is built on them. See [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/).

**Can I let it run on its own?** Sometimes, with care. Autonomous mode runs the loop without you in it. When to trust it is its own question, covered in [What Is Autonomous Mode?](/2026/06/02/what-is-autonomous-mode/).

**Does this replace software engineers?** No. It moves the work. The cost of writing code fell; the cost of deciding what to build did not. [How AI Is Changing Software Engineering](/2026/05/27/how-ai-is-changing-software-engineering/) is the long answer.

**Does this apply to infrastructure?** Yes, and the payoff compounds there. The same loop runs on Dockerfiles, CI pipelines, and infrastructure code. [Recursive DevOps](/2026/06/05/recursive-devops/) is where I take that to its end.

## 12. Where to go next

This document is the entry point. The cluster behind it goes deeper:

- [AI-Assisted Engineering](/ai-development/), the hub that collects every essay and field note in one place. Start there if you want the map.
- [How AI Is Changing Software Engineering](/2026/05/27/how-ai-is-changing-software-engineering/), the field report on where the bottleneck moved.
- [An AI Agent Workflow for Software Engineers](/2026/06/02/ai-agent-workflow-for-software-engineers/), the core loop in full.
- [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/), what compounds across a long engineering career.
- [AgentSpek](/books/agentspek/), my book on building this way, free to read here.

All of this is the practical application of one larger idea I keep coming back to, [making complexity visible](/making-complexity-visible/): keeping a system understandable enough to navigate without pretending it is small. AI-assisted engineering is where I apply it every day.

## 13. A note on the meta

I built this manual the way it tells you to build software. I specified it, delegated the draft to an agent in the exact agent mode described above, verified every command against the live tools, and recorded the decisions as I went. The document is an instance of its own method. That is the meta.

The meta of the meta is the memory file. The `CLAUDE.md` and the voice rules that governed how this got written are the same kind of standing intent section 4 tells you to keep, pointed at prose instead of code. The thing that shaped the writing is itself a project memory file.

And the Übermeta, with the umlaut it has earned: the method applies to itself, all the way up. Building the thing, writing about building the thing, and setting the rules for how that writing is done are one loop running at three heights. This is [Recursive DevOps](/2026/06/05/recursive-devops/) pointed at language. The system that makes the work and the system that improves the system are the same system. Once you see it you do not unsee it. Good. Now go build something.

## Appendix A: A starter memory file

Drop this at the repo root as `CLAUDE.md` for Claude Code, and as `.github/copilot-instructions.md` for Copilot agent mode. Same content, both files. Fill in the brackets. Keep it short and true; a file that lies to the agent is worse than no file.

```markdown
# Project Memory

## What this is
[One or two sentences. What the project does, who uses it.]

## How it is built and run
- Install: [command]
- Dev: [command]
- Test: [command]
- Build: [command]

## Conventions that matter
- [The naming, structure, or style rules you actually enforce.]
- [How errors are handled here.]
- [Anything a newcomer always gets wrong.]

## Do not touch without care
- [Files or systems that are load-bearing and easy to break.]
- [The rule for changing them.]

## Lessons (append as you go)
- [Mistakes the agent made, so it stops repeating them.]
```

## Appendix B: Spec and ADR templates

Two more good ideas worth keeping as templates. The first is for the Specify step: write the intent before you prompt. The second is the ADR I keep one of per real decision.

A spec you hand the agent:

```markdown
# Intent: [one-line outcome]

## Outcome
[What is true when this is done.]

## Constraints
- [What it must not break.]
- [What it must stay compatible with.]

## Non-negotiable
- [The parts there is no flexibility on.]

## Done when
- [The check that proves it works: behavior, not exit code.]
```

An ADR you write when you decide something real:

```markdown
# ADR-[NNN]: [the decision in a few words]

**Status:** [Proposed | Accepted | Superseded]
**Date:** [YYYY-MM-DD]

## Context
[The situation that forced a choice.]

## Decision
[What we are doing, in plain language.]

## Consequences
[What this makes easy, what it makes hard, what we gave up.]
```

## Appendix C: Command cheat-sheet

The commands from this manual in one place. Terminal commands are for Claude Code; the slash commands run inside a session.

```bash
# Start and choose a model
claude                          # interactive session in the current repo
claude --model sonnet           # start on Sonnet (default for daily work)
claude --model opus             # start on Opus (hard reasoning)

# Pick up past work
claude --continue               # resume the most recent session here
claude --resume                 # choose from past sessions

# Headless, for scripts and pipes
claude -p "one-shot prompt"     # run once and exit
cat file.log | claude -p "..."  # pipe input in

# Parallel agents via git worktrees
git worktree add ../proj-x -b feature-x
git worktree list
git worktree remove ../proj-x
```

```text
# Inside a session
/model opus | /model sonnet     # switch model mid-task
/context                        # what is filling the context window
/clear                          # wipe conversation, keep the memory file
/compact                        # summarize and continue
/init                           # generate a starter CLAUDE.md
/memory                         # show loaded memory files
/agents                         # configure subagents
Shift+Tab                       # cycle permission modes (ask / auto-edit / plan)
Esc                             # interrupt a run that is going wrong
```

## About this document

Written by Joshua Ayson, a DevOps engineering leader who builds this way every day. Corrections and better tips are welcome; like the HOWTOs I learned from, this one gets revised.

- *Revision 1.0, June 2026.* First cut: setup, the loop, tips, failure modes.
- *Revision 1.1, June 2026.* Added the tools I actually use (Claude Code and Copilot agent mode), the memory-file split, context and token management, verified commands, and a cheat-sheet.

If it saved you an afternoon, it did its job.]]></content:encoded>
      <pubDate>Sat, 06 Jun 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/06/ai-assisted-engineering-howto/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/ai-assisted-engineering-howto.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>EGO IS AN INCH: a beat-locked Alan Watts rap on the self you can never grab</title>
      <link>https://joshuaayson.com/2026/06/06/ego-is-an-inch/</link>
      <description>EGO IS AN INCH is Song 07 in Out of Your Mind, the Napkin Films series built from the Alan Watts lectures. It is the one about the ego: an abstraction like an inch or a line of longitude, useful for measuring and impossible to pick up, because the thing reaching is the thing reached for. A Bavarian governor voice raps it over Mussorgsky&apos;s grotesque Gnomus reborn as Eb-minor EDM, while a Plan 9 bunny, recast as the inch itself, taunts from just out of reach. CC BY 4.0.</description>
      <content:encoded><![CDATA[Try to grab it. It vanishes.

EGO IS AN INCH is Song 07 in **Out of Your Mind**, the Napkin Films series built
from the Alan Watts lectures. This is the one about the ego. Watts liked to say the
ego is an abstraction, like an inch, or a line of longitude. Useful for measuring,
but you cannot pick it up and put it in a box. Reach for it and your hand closes on
nothing, because the thing doing the reaching is the very thing it is reaching for.
The eye cannot see itself seeing. The hand cannot grab the hand that grabs. So the
self you keep trying to hold turns out to be a ruler's tick, a convention, a
measurement mistaken for a thing. Stop grabbing and there is just the grabbing, just
the looking, just this.

## Why the music IS the idea

The theme is the self that disappears the instant you clutch at it, so the sound had
to be the grab-and-miss made audible. I reached for Mussorgsky's **Gnomus**, the
lurching gnome from Pictures at an Exhibition, and recomposed it into Eb-minor
grotesque EDM with ChipForge, my own no-GPU, no-samples music engine. It is jagged
and comic, because the ego grabbing at itself is a little grotesque and a little
funny. A Neapolitan E major keeps diverting every cadence, so the music itself is
always reaching and never quite landing.

The bespoke device carries the whole concept. It is the **vanishing inch**: a
staccato grab figure that loses a note every bar across each four-bar phrase, so by
the fourth grab it catches almost nothing, and a celeste pop marks each note as it
winks out. Above it a harpsichord grabs one bar too late, echoing the figure that
already passed, the hand that grabs unable to grab the hand grabbing. Nobody has to
explain the idea. The arrangement enacts it.

## Voices and picture

Der Gouverneur, a Bavarian philosopher governor voice, raps it in English and
German, every line stretched to a whole number of beats so it locks to the grid. The
Plan 9 Glenda bunny, the on-screen character, is recast here as **the inch itself**,
taunting from out of reach: missed again, whiff, gone, that's you. A German grab
motif runs underneath, wer schaut, ohne Griff, ohne Greifer: who is looking, no
grip, no grabber.

The picture is stick-figure simple, a vanishing gold inch the bunny keeps swiping at
and missing, a ruler of ticks, longitude arcs, an empty dotted outline where the
self should be. The climax is the only one in the series that goes down rather than
up: a red mirror-collapse, the lagged ghost-bunnies folding into one that still
catches nothing, the punchline landing.

## Made on a laptop

Stick-figure simple in Python and PIL, a beat-locked spit-rap, a second character
voice, a ChipForge Mussorgsky recomposition, real drums and bass. Generated locally.
No GPU, no subscriptions, no stock footage. Written, directed, composed, animated,
voiced, and produced by Joshua Ayson with AI, for Organic Arts LLC.

Watch it here: https://youtu.be/syRBFyepPiY

Licensed CC BY 4.0. The music is an original ChipForge arrangement inspired by the
public domain works of Modest Mussorgsky; the source was studied for structure only,
nothing was sampled. The words are adapted and compressed from Alan Watts, Out of
Your Mind.]]></content:encoded>
      <pubDate>Sat, 06 Jun 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/06/ego-is-an-inch/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/ego-is-an-inch-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>The Cognitive Cost of Modern Software Engineering</title>
      <link>https://joshuaayson.com/2026/06/05/the-cognitive-cost-of-modern-software-engineering/</link>
      <description>AI took the typing, and the cost of software engineering did not go away. It moved from the hands to the head and got heavier. The new scarce resource is your attention, and the new discipline is managing it.</description>
      <content:encoded><![CDATA[# The Cognitive Cost of Modern Software Engineering

*AI took the typing, and the cost of building software did not go away. It moved, from the hands to the head, and on the way it got heavier. The work is more productive than it has ever been and more tiring than it has ever been, and those two facts are the same fact. This is the part the pitch leaves out.*

The story everyone tells about AI and software engineering is a story about speed. The code writes itself. A month of work becomes an afternoon. That story is true, and I have lived it, and it is the least honest version of what happened, because it implies the work got easier. It did not get easier. It got more concentrated, and concentration has a price that you pay with your mind, all day, without the breaks the old work used to give you for free.

I want to describe that price plainly, because I have not seen many people name it, and because naming it is the first step to managing it. The companion to this is [Agent Mode Changes the Shape of Thought](/2026/06/05/agent-mode-changes-the-shape-of-thought/), which is about the opportunity. This one is about what the opportunity costs you, and it is not a small thing.

## The bottleneck moved, and so did the cost

I have written software professionally for over fifteen years. I have said elsewhere, in [how AI is changing software engineering](/2026/05/27/how-ai-is-changing-software-engineering/), that the headline is short: AI did not replace engineers, it moved the bottleneck. The cost of writing code dropped to near zero, and the cost of deciding what to build, how to architect it, and when to ship became the whole job.

Follow that one step further than the productivity articles do. If the bottleneck moved, the cost moved with it. The work did not lose its weight. The weight relocated. It used to sit in your hands and your hours, in the sheer volume of typing and stitching and translating that a week of building required. Now it sits in your head, in the unbroken sequence of decisions that is all that remains when the typing is gone. And the head is a more expensive place to spend than the hands, because the hands can work while the mind rests, and the mind cannot rest while it is the only thing working.

That is the whole essay in one sentence, but the sentence stays abstract until you have felt the specific ways the cost shows up. So let me be concrete about them.

## Typing was rest, and nobody says so

Here is the thing I did not understand until it was gone. The mechanical part of programming, the part that AI took, was never the hard part, and everyone knew that. What nobody said is that it was also a kind of rest.

For most of my career a real share of a working week was typing. Boilerplate. Translating a clear idea into a verbose language. Wiring API responses together. Writing the tests that exercise the mechanical paths through code I had just written. Updating the documentation after the refactor. None of that was where the engineering lived. But it was where the day had its valleys. After you made the hard decision, you got to spend an hour or two simply executing it, and the executing was a place the mind could idle. You were producing real work and recovering at the same time. The hands moved and the deeper part of you got to coast.

Take that away and the valleys disappear. The day becomes a ridgeline. Decision after decision, with no flat stretch in between, because the flat stretches were exactly the parts the agent now does in seconds. I describe what I want, and before I have finished my coffee the change is back and it needs a judgment from me. There is no longer an hour of mechanical typing to hide inside while my mind catches its breath. The breath-catching has to be scheduled now, deliberately, because the work will not hand it to you the way it used to.

This is not nostalgia for boilerplate. I do not miss the typing. I am pointing at a real ergonomic fact that the productivity framing erases: the old work had built-in recovery, and the new work does not, and if you do not replace that recovery on purpose you will run yourself down at a rate the old job could not have managed.

## What is left is judgment, and judgment is expensive

When the typing goes, what remains is louder, and all of it is the costly kind of work.

I read more code now than I ever have, and most of it I did not write. Reading code was once maybe a tenth of the job. It is closer to two thirds of mine now: absorbing an unfamiliar stretch the agent just produced, deciding whether it is correct, whether the error handling is right, whether it interacts cleanly with the rest of the system, whether it quietly made an architectural choice while I was looking away. Reading is more tiring than writing, because writing your own code carries you forward on your own intent, and reading someone else's, even a machine's, means reconstructing an intent from the outside and checking it against what you actually wanted. You are doing that, at speed, all day.

Deciding what to build is now the front of the work instead of the preface to it. A model will build the wrong thing beautifully and fast, and the cost of a wrong decision used to be amortized across the weeks it took to implement. Now the wrong thing arrives in an afternoon, fully formed, and you either live with it or back it out. The pressure on the quality of your specification, on knowing what you actually want before the machine commits you to a polished version of a guess, is constant and it does not relent.

And there is a decision that barely existed before and is now one of the most important and most draining: knowing when to stop the agent. Agents do not get tired and they do not stop. They will refactor what did not need refactoring, scaffold for problems you do not have, keep going confidently past the point where they should have asked. The discipline to interrupt, redirect, and reject is the new craft, and restraint is the most expensive new failure mode, because the temptation to do more, faster, simply because you can, is always right there, and saying no to it dozens of times a day is its own kind of fatigue.

None of these are the parts of engineering that let your mind coast. They are the parts that demand all of it. The job did not get smaller. It got distilled down to nothing but its hardest fraction, and then you do that fraction continuously.

## The new failure mode is overload, not slowness

For my whole career the limiting factor was throughput. You could only produce so much in a day, and the failure mode was being too slow: the project that took too long, the backlog that grew faster than you could burn it down.

That failure mode is mostly gone, and a stranger one took its place. When a two-week project ships in two days, the obvious move is to run ten of them at once across the same calendar, because you can. I have done exactly this. And it does not give you more leisure. It gives you ten times the judgment to supply, ten streams to keep coherent, ten contexts to hold and switch between, ten places where a confident mistake can slip through because your attention was on stream seven when stream three went wrong.

The bottleneck is no longer how fast you can produce. It is how much you can hold without losing the thread. That is a cognitive limit, not a physical one, and it is a real ceiling. Past a certain number of live streams the coherence starts to fray, you stop catching the thing heading the wrong direction, and the very capability that let you take on ten projects becomes the reason all ten degrade at once. The new way to fail is not to be too slow. It is to take on more than one mind can keep clear, at the exact speed that makes that easy to do without noticing.

## The intensity is real, and it has a body

I do not want to keep this abstract, because the cost is not abstract. I lived its sharpest version in a stretch I wrote about as [six weeks living at machine speed](/2025/07/22/the-multithreaded-mind-six-weeks-living-at-machine-speed/).

In those weeks time stopped behaving normally. I wrote in my journal that a single month felt like a year. The line between my own thinking and the machine's processing mostly stopped existing. I was meeting more frameworks and systems in a week than I used to read about in a year, all of it at once, none of it letting up. My computer ran hot from the load, and that heat was a fair picture of what was happening inside my head. I wrote, plainly, that working with a partner all day, whether human or not, is tiring. The tiredness came with a charge to it, and both things were true. We were building about as fast as I could think, and thinking that fast for that long has a cost your body will eventually present to you.

The part I want to flag is what happened to rest. When you can make an idea real about as fast as you have it, sleep starts to feel like an interruption. I have the timestamps to prove it: Thursday 2am commits, Friday 4am pushes, weekend marathons, not because anything forced me but because I could not put it down. That is the seductive shape of this work. It does not exhaust you against your will. It exhausts you with your full enthusiastic cooperation, because the loop between idea and result got so tight and so rewarding that stepping out of it feels like loss. The old job protected you a little by being slow. This one removes the protection and replaces it with a thrill, and a thrill is not a substitute for sleep no matter how convincing it is at 3am.

## The scarce resource is now you

Put all of it together and the conclusion is uncomfortable and clarifying at once. The scarce resource in modern software engineering is no longer compute, or time, or the supply of people who can type the code. It is your own attention, your clarity, the amount of context you can hold at once without it going blurry.

Picture it as a loom. The parallel [threads of work you run at once](/2026/01/28/on-threads/) are exactly that, threads, and a thread on its own is just a loose strand. Attention is the frame that holds the threads in tension and turns them into a fabric instead of a tangle. The weave is only ever as good as the loom, and a loom has a width. Run more threads than it can hold and they slacken and cross, and the pattern you were making comes apart in your hands. The machine can spin thread faster than anyone ever has. What it cannot do is widen your loom. That part is fixed, it is yours, and everything you make is woven on it.

The machine took over the part that scaled with hours, and handed back the part that scales with the quality and the freshness of your mind. Which means your mind is now the constraint on everything, and a constraint is something you have to manage deliberately or it manages you.

This reframes what it means to be good at this job. It is no longer mainly about how much you can produce, because production is cheap. It is about how well you can protect and direct the one input that is now scarce. The most productive thing I can do on a given day is often not to open another stream. It is to keep my head clear enough that the streams I already have get real judgment instead of a tired approximation of it. That is a sentence I would have found ridiculous a few years ago, when the obvious path to more output was more hours. The path to more output now runs through a rested, clear, undivided mind, and that mind is finite in a way that the old bottleneck never made you confront.

## How you pay it down

So the discipline that this era actually demands is not a new framework or a faster tool. It is the management of your own cognition as the scarce resource it has become, and most of it is unglamorous.

The first move is legibility. The thing that overwhelms you is not the size of the system, it is the system being illegible, too tangled to hold in your head, so that every decision costs more than it should because you have to reconstruct the whole shape before you can reason about a part of it. The defense is to keep the system understandable on purpose, to spend real effort making the complex thing simple enough to reason about, which is the larger idea underneath everything I build, the practice of [making a complex system legible enough to live inside](/coherent-complexity/). A legible system is cheap to think about. An illegible one taxes you on every single move, and the tax compounds.

The second move is restraint, which I have already named as the new craft and will name again because it is that important. Not every project that can be run should be run. Not every refactor the agent offers should be taken. The capacity to do more is not a reason to do more, and the engineers who burn out fastest in this era will not be the ones who could not keep up. They will be the ones who could, and did not know where to stop. Saying no to your own capability is now a core professional skill.

The third move is to treat rest as part of the work rather than a failure of it. The old job built recovery into the day and you could afford to be careless about it. This one does not, so you have to put it back deliberately, and you have to defend it against the thrill that tells you the loop is too good to leave. Sleep is not an interruption of the work. It is the maintenance of the only instrument the work now depends on. I came to this the hard way, and it is the same antifragile instinct I try to apply everywhere, that a little structure and a little protection on the downside is what lets a system, or a person, [gain from intensity instead of being broken by it](/2026/05/30/living-with-antifragility/).

The last move is to know your own limit, honestly, the number of live streams past which your coherence frays, and to stop short of it on purpose. That number is real, it is personal, and it is lower than your ambition wants it to be. Finding it and respecting it is the difference between using this capability for a long time and using it brilliantly for a while and then crashing.

There is a practical version of all of this that I had to learn by hand: protect blocks of single-threaded attention on purpose, where you run one stream and let the loom hold a single clean pattern instead of a dozen fraying ones. The instinct of the era is to parallelize everything, because you can, and some of the most valuable work I do now is the deliberate refusal to, the hour given over to one hard problem with my whole undivided head. The machine made breadth cheap. Depth stayed expensive, and depth is still where the hard decisions get made well.

## The work got more human, not less

There is a fear that AI hollows out engineering, turns it into prompting, removes the craft. My experience is close to the opposite, and the cost is the proof. The machine took the parts that were mechanical, the typing and the translation, the parts that were never really you. What it left behind is the parts that are nothing but you: the taste to know what is worth building, the judgment to know when something that looks right is wrong, the clarity to hold a complex thing in your head, the restraint to stop. Those parts are expensive precisely because they are human, and they cannot be delegated, and there is now nowhere to hide from them inside an afternoon of comfortable typing.

That is why the work is more tiring even as it is more productive. You are spending the whole day in the part of yourself that costs the most to spend. The bargain is real and it is good, but it is a bargain, and pretending it is free is how people get hurt by it. Name the cost, manage the resource, protect the mind, and you can do this for a long time and love it. Ignore the cost because the productivity numbers are intoxicating, and the resource that the whole thing depends on, which is now you, will run out, quietly, at the exact moment you are most convinced you are invincible.

If you want the method I run inside all of this, it is the [book-length version in AgentSpek](/books/agentspek/), free here, and the rest of how I build this way lives at [AI-Assisted Development](/ai-development/). But the most important tool is not in any of them. It is the discipline of guarding the one resource that does not scale, and that, unlike the typing, no machine is going to take off your hands.]]></content:encoded>
      <pubDate>Fri, 05 Jun 2026 22:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/05/the-cognitive-cost-of-modern-software-engineering/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/the-cognitive-cost-of-modern-software-engineering-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Recursive DevOps</title>
      <link>https://joshuaayson.com/2026/06/05/recursive-devops/</link>
      <description>DevOps was always a feedback loop. The first one ran between people. The one worth building now runs the system back on itself, so every failure and every change makes the next one cheaper and safer. The recursion is the compounding.</description>
      <content:encoded><![CDATA[# Recursive DevOps

*DevOps was always a feedback loop. The first version of it ran between people. The version worth building now runs the system back on itself, so that every failure and every change feeds forward into a system that is cheaper and safer to change next time. The recursion is the whole compounding mechanism, and most teams never turn it on.*

I have spent fifteen years inside the DevOps thesis, as a practitioner, then a lead, then someone running platform organizations. The longer I do it, the more I think the original idea was both completely right and quietly mislabeled. It got remembered as a thesis about automation. It was really a thesis about loops. And once you see it as a thesis about loops, an obvious question appears that the industry mostly did not ask: a loop between what and what, and how many times does it run.

This is the answer I have arrived at. The most valuable thing you can do in operations is not to automate the work. It is to close the loop on the system itself, so the system becomes the thing that improves the system. I have written the broad version of why systems thinking is the part that compounds in [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/). This is the narrower, sharper claim underneath it.

## The loop was the original idea

The original DevOps argument was simple and correct. Developers and operators were optimizing against each other, the friction between them was the single largest source of incidents, and the cure was to put them in the same loop. Deploy small changes often. Automate the path from commit to production. Measure what matters. Share responsibility for the running system, not just the code that produced it.

Every word of that is still true. But notice the shape of it. The cure was not a tool. The cure was a feedback loop. Put the people who write the change and the people who run the change into one circuit, so that the consequences of a decision reach the person who made it, quickly, while they can still do something about it. That is the actual invention. The pipelines and the dashboards and the alerting were just the wiring that made the loop fast.

When you see the loop as the invention, the tools stop being the point. A loop is a pattern, and a pattern can be applied to more than the thing it was discovered on. The first DevOps loop closed between two groups of humans. The interesting move is to ask what else you can put inside a loop, and what happens when the loop starts feeding into the very thing that produced it.

## From a loop between people to a loop on the system

Here is the shift. The original loop ran from the system to a human and back: the system did something, a human saw it, the human changed the system. That is already valuable, and it is most of what teams build. But the human in the middle is a bottleneck, and more to the point, the human keeps having to learn the same lesson because nothing about the system itself changed to remember it.

A recursive loop closes the circuit one level deeper. The system does something, a human sees it, and then the human changes the system so that the system itself now handles that case, or makes it impossible, or surfaces it earlier next time. The output of one pass is a permanent change to the thing that will run the next pass. The loop is no longer just operating the system. It is reshaping it, and each reshape changes what the next reshape starts from.

That is what I mean by recursive DevOps. Not infinite cleverness. A discipline of always closing the loop one level deeper than the incident, so that the work you do this week lowers the cost or the risk of the work you do next week. If your operational effort this month did not make next month's operational effort cheaper, you did maintenance. Maintenance is necessary, but it does not compound, and the whole game in a long-lived system is compounding.

## A failure is an input, not the enemy

The cleanest example I have is the day an agent-written deploy script deleted most of production.

The script was good. It built the site, synced the files to a bucket, and cleaned up anything stale so the live state matched the build exactly. That last behavior, deleting whatever was not in the new build, is correct right up until the build comes up short. One day a build failed partway through, produced an incomplete set of files, and the script did exactly what it had been told. It made the live site match the incomplete build, which meant deleting most of the images from production. I have written the longer version of this in [how I rebuilt this site in agent mode](/2026/06/03/rebuilt-my-site-in-agent-mode/), but the part that matters here is what I did with the failure.

The non-recursive response would have been to fix the immediate problem. Re-upload the images, clear the cache, move on, and add a line to a runbook telling the next person to be careful. That closes the loop at the human level. The lesson lives in a person, the system is exactly as dangerous as it was, and the failure is waiting to happen again to someone who has not read the runbook.

The recursive response is to change the system so the failure cannot recur. I pushed the images back with a sync that only adds and never deletes, and then I changed the deploy itself so that a bad build can no longer reach a destructive step, and so asset uploads only ever add. The failure became a permanent improvement to the shape of the system. The system now knows something it did not know before, not in a document, in its structure. That is the only good thing a failure is for, and a failure that you spend on a runbook line instead of on the architecture is a failure you have agreed to suffer again.

This is what people mean, or should mean, by antifragile, and it is the same instinct I try to bring to everything I build, the practice of [making systems that gain from disorder](/2026/05/30/living-with-antifragility/) rather than ones that merely survive it. A robust system takes the hit and stays standing. A recursive system takes the hit and comes out the other side unable to take that particular hit again. The disorder is not the thing you are defending against. It is the input. Every incident is a free piece of information about where your system is weak, paid for in pain you have already spent. The only waste is to spend the pain and not collect the information.

The discipline that makes this routine is naming failure modes before they happen and rehearsing them. The platform itself keeps teaching me to do it: assume the part will fail, decide in advance what happens when it does, and build so that the answer is already known. What happens when a deploy is incomplete. What happens when a cache header is wrong. What happens when a path that worked on the old host does not resolve on the new one. Each of those questions, asked early, is a small recursion run on purpose instead of waiting for the system to run it on you at three in the morning.

## Make the runbook unnecessary

There is a tell that separates teams that are looping recursively from teams that are just automating, and it is the runbook.

Automation looks at a nine-page runbook and asks how to execute it faster. It writes the script that runs the steps. This feels like progress, and it produces real, measurable savings, and it is the easy half of the job. The hard half, the recursive half, looks at the same nine-page runbook and asks a different question: why does this need to exist at all? A system that requires fifteen humans to interpret seven dashboards to decide whether it is safe to deploy on a Friday is not a system that needs more automation. It is a system that needs a different shape. Automation built on top of a confused architecture just amplifies the confusion at higher speed.

I have written a lot of runbooks. The work that actually moved the incident rate down was almost never the runbook. It was the work that made the runbook unnecessary. The runbook is the symptom. The architecture that produced it is the disease, and you can spend a career treating symptoms very efficiently while the disease compounds underneath.

So the recursive move on any piece of operational toil is to ask whether this pass eliminates the need for the next pass, or merely speeds it up. Automating a manual step that should not exist is a local optimum that locks in the thing you should have removed. The deeper version of the question, the one that pays off over years, is the one most organizations are bad at, because they are exquisitely good at calculating the cost of doing something and catastrophically bad at calculating the cost of not doing it. The five-year-old instance nobody will touch because nobody knows what runs on it is a cost. The fragile deploy everyone is afraid to refactor is a cost. The migration the team has spent four years not doing is a cost. Automation does not surface those. Only judgment does, and judgment is the part of this that does not get automated, which is exactly why it is the part that keeps mattering.

## The platform that improves the platform

Around 2022 the industry started calling the mature version of this platform engineering, and the rename was useful because it made the recursion explicit. The platform is a product. The application teams are the customers. And the platform team's entire mandate, the whole of it, is to make the next line of application code easier and safer to ship than the previous one.

Read that mandate as a function and it is openly recursive. Each thing the platform team ships is supposed to lower the cost of the next thing everyone else ships, which lowers the cost of the thing after that. A platform feature that nobody adopts is not neutral. It is debt, because it added surface area without lowering anyone's cost of change. The platform team's success is not measured by how much they ship. It is measured by how much the application teams ship because the platform exists. That is a derivative, a rate of change of someone else's velocity, and optimizing a derivative is a fundamentally different posture than optimizing your own output.

This is the recursion at the organizational scale. You are not building the product. You are building the thing that builds the product, and then improving the thing that builds the thing, and the payoff lives in how many downstream changes each upstream change makes cheaper. A team that internalizes this stops measuring itself by tickets closed and starts measuring itself by friction removed, which is the only metric that compounds.

## Agent mode closes the loop faster

Everything above was true before AI agents entered the workflow. What agent mode changes is the cost of a single pass through the loop, and lowering that cost changes how often you can afford to run the recursion.

A lot of the routine platform work that used to take a junior engineer a week now takes a senior engineer a morning. Writing the Terraform module, scaffolding the service, generating the CI workflow, drafting the runbook, and crucially, performing the reshape that makes the runbook unnecessary: all of that compresses hard. When the mechanical cost of changing the system drops toward zero, the recursion gets cheaper to run, and things that were too expensive to bother fixing become worth fixing. The half-day refactor that removes a class of incident was never worth a week of a person's time against everything else on the board. At a morning, it is obviously worth it. So the loop runs more often, and a loop that runs more often compounds faster.

The economics of the team shift with it. The old question was how many junior engineers you needed to do the rote work. The new question is how many senior engineers you need to direct the rote work the agents now do, and the ratio inverts. A platform team stops being measured by its capacity to produce configuration and starts being measured by the quality of its judgment about which configuration is worth producing. That is a smaller team doing higher-altitude work, and it is only an improvement if the judgment is actually there. Invert the ratio without the systems literacy to aim the agents and you have not made the team better. You have given it a faster way to generate operational debt, because the agents will widen whatever loop you point them at, the compounding one or the destructive one, with equal cheerfulness.

But there is a sharp edge, and it is the same edge I described in [Agent Mode Changes the Shape of Thought](/2026/06/05/agent-mode-changes-the-shape-of-thought/). The agents are very good at the steps and very bad at whether the steps are the right steps. An agent will happily build a beautifully clean pipeline that solves the wrong problem. It will write a Terraform module that provisions infrastructure your team cannot operate. It will refactor a deploy script in a way that breaks a tribal-knowledge invariant nobody wrote down. This is not a flaw in the agents. It is a clarification of where the engineering always was. The agents have made it impossible to fake the systems-thinking part of the job, because they will produce an enormous volume of confident, plausible work that quietly increases the operational debt if a real judgment is not steering it.

So agent mode does not run the recursion for you. It turns the crank. It makes each pass cheap. The thing that decides whether the loop compounds or just produces more system faster is still a human deciding which failure is worth turning into a permanent improvement, which change actually lowers the cost of the next change, and which part of the system to point the loop at next. The agent makes the reshape cheap. It cannot tell you that the reshape was worth doing, or that you reshaped the right thing.

## Pointing the recursion

The practical version of all of this fits on one question, which I now ask of nearly every piece of operational work: does this pass make the next pass cheaper, or does it just get me through today?

If it gets me through today, it is maintenance, and sometimes maintenance is what the day requires. But if I find that almost everything I am doing is getting me through today, I am running an open loop. I am operating the system and learning nothing into it. The recursive habit is to spend a fixed fraction of every incident and every change on closing the loop one level deeper than the problem in front of me. The incident becomes a structural change that makes it impossible. The change becomes a lowering of the cost of the next change. The runbook becomes an architecture that needs no runbook.

The signals that tell you whether the recursion is working are the boring operational numbers, and they are honest in the way that physics is honest. I have written about how [AWS is math and Kubernetes is physics](/2026/05/31/aws-is-math-kubernetes-is-physics/), how one discipline bills you in money and the other in latency and contention. Those bills are the feedback. The cost trend, the incident rate, the time it takes a new engineer to ship safely, the length of the runbook: those are the readouts of whether each pass is making the system cheaper to change or more expensive. A recursive practice bends them in the right direction over quarters, not because of any single heroic fix, but because the loop is pointed at making the next thing easier, and it keeps running.

## The system that gets stronger from what hits it

DevOps started as a loop between people, and that was the right place to start, because the friction between people was the first bottleneck. The version I am describing is the same idea taken one level deeper: a loop the system runs on itself, with a human pointing it and agents turning the crank fast enough that you can afford to run it constantly. The output of the loop is not a deployment. The output of the loop is a better system for producing the next deployment, and a better system again after that.

The aim, in the end, is a system that gets stronger from what hits it. Not one that resists disorder, but one that converts it, that takes every failure and every awkward change and every painful migration and comes out structurally improved, unable to suffer that exact thing again, cheaper to change than it was the day before. That requires keeping the whole growing thing legible enough to actually reason about, which is the larger idea underneath everything I build, the practice of [making a complex system legible enough to live inside](/coherent-complexity/), whether the system is a cloud platform, a codebase, or a life. The agents will turn the crank as fast as you let them. Whether the loop compounds is the part that is still, and will remain, yours.

If you want the broader argument for why systems literacy is the skill that survives, it is in [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/), and the book-length version of how I work this way is [AgentSpek](/books/agentspek/), free to read here. The rest of how I build lives at [AI-Assisted Development](/ai-development/).]]></content:encoded>
      <pubDate>Fri, 05 Jun 2026 21:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/05/recursive-devops/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/recursive-devops-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Agent Mode Changes the Shape of Thought</title>
      <link>https://joshuaayson.com/2026/06/05/agent-mode-changes-the-shape-of-thought/</link>
      <description>Agent mode is not a faster way to type. It moves the unit of thought up from syntax to intent, turns you into a conductor of parallel work, and makes the real bottleneck the clarity you can hold in your head at once.</description>
      <content:encoded><![CDATA[# Agent Mode Changes the Shape of Thought

*The speed story is the easy one to tell and the least interesting. What actually changes when you build software in agent mode is the unit you think in, the number of things you can hold at once, and where the hard part of the work goes to live.*

When people describe agent mode, they almost always reach for speed. It writes the code faster. It does in an afternoon what used to take a month of evenings. That is true. I have said it myself. And it is the shallow version, because it measures a new thing with the old ruler.

The deeper change is harder to see, because it happens inside your head instead of on the screen. I have been working this way for the better part of a year, and the thing I keep noticing is not that I produce more. It is that I think differently. The shape of the work changed. The unit I reason in moved up a level. The number of things I can hold in flight went up with it. And the part of the job that is actually hard relocated to a place it never used to live.

This is an attempt to describe that change plainly, from the inside.

## First, the plain definition

If you have not used it, here is the short version. I wrote a [longer one separately](/2026/06/02/what-is-agent-mode/). Agent mode is when you stop typing code and start directing an AI that reads your codebase, makes the change across as many files as the task needs, runs the tests, and reports back. You describe the outcome. It does the work and checks itself. You review, correct, and send it again.

The loop is not write, compile, test. It is specify, generate, verify, specify. You say what you want clearly enough that an agent can act on it. It produces the change. You confirm the result is right, or you catch that it is wrong. Then you correct course and go again.

Notice where the hours go in that loop. Not into typing. They go into the first step and the third: being precise about what you want, and checking that you got it. Hold onto that, because everything that follows comes out of it.

## The unit of thought moves up

For most of the history of programming, the unit of thought was small. You held a function in your head. You held the line you were typing, the variable you were tracking, the bug three calls down the stack. Even with good autocomplete the unit did not really change. Autocomplete finishes the line you are already writing. You are still the one holding the whole task in your head, typing it out one suggestion at a time. The machine is a faster keyboard, not a different altitude.

Agent mode moves the altitude. I am no longer working at the level of the keystroke, or even the function. I am working at the level of the task, and increasingly at the level of the system. I do not think "write a loop that does this." I think "this endpoint needs rate limiting and the tests need to cover the new failure case," and that sentence is the work. The agent reads the relevant files, writes the change, runs the suite, and comes back with a diff. I was never in the editor. I was holding the intent.

That shift sounds small and it is not. When the unit of thought is a function, your day is a thousand tiny acts of translation: turning what you want into the exact syntax that produces it. When the unit of thought is a task, that translation layer mostly disappears, and what is left is the thinking it used to bury. You spend your attention deciding what should exist and whether what came back is correct. The grammar stops being the bottleneck. The idea becomes the bottleneck, which is a much more honest place for it to be.

I noticed this most clearly the first time I described an outcome instead of a procedure. I needed to stand up an AWS service behind CloudFront with a private S3 origin and a password gate at the edge. The old way was to read the documentation, write the infrastructure code, wire the origin access control, debug the bucket policy, fix the cache behavior, and repeat until it held. In agent mode I described the end state: private bucket, served only through this one distribution, gated by a password at the edge. The agent wrote the configuration, explained the wiring, and flagged the single gotcha that breaks these setups. My job was to decide the design and verify the result, not to remember the order of the arguments. The cost of writing the configuration dropped to almost nothing. The cost of deciding what to build and confirming it was right became the entire job.

## The bottleneck moves off your hands

This is the part the hype skips. Working in agent mode is not less engineering. It is more of the engineering that matters and less of the typing that does not.

For years the limiting factor on what one person could build was production. There were only so many hours, and the hours went into making the thing. Agent mode takes the cost of making the thing and drives it toward zero. What is left is what was always the real job and was always crowded out by the typing: knowing what to build, and knowing when something that looks right is actually wrong.

So the bottleneck moved. It used to sit in your hands, in how fast and how long you could produce. Now it sits in two places, and both are upstream of any code. The first is the clarity of your intent. Vague intent produces a polished version of the wrong thing, fast, so the act of being precise about what you want is no longer a preface to the work. It is the work. The second is the rigor of your verification. AI-generated code can pass every test you wrote and still be wrong, because it can satisfy the letter of a specification while missing the thing you actually meant. So checking is not a formality at the end. It is half the job, and it does not get easier as the production gets faster. If anything it gets harder, because there is more output arriving and less of it passed through your own hands on the way.

When I [rebuilt this site in agent mode](/2026/06/03/rebuilt-my-site-in-agent-mode/) and moved it off shared hosting onto AWS, that is exactly where my attention went. I was not writing the components or the deploy configuration. I was deciding what the site should be, reading the diffs, catching the architectural choices that would cost me later, and saying yes or no. The thing that did not drop, the thing that became more important than before, was judgment.

## Scaling cognition, not output

The part that still surprises me is what happens when it is not one agent but several.

With one agent you are a person directing a fast collaborator. With several you become something closer to a conductor. One agent is refactoring a module while another drafts a migration while a third checks a result. You are holding more in flight than a single human working alone could hold, and the holding is the skill. The bottleneck moves off your hands entirely and onto your ability to keep several streams coherent at once: to know which one needs you now, to feel when one is confidently heading the wrong direction, to keep the whole shape in your head while the pieces move.

This is where I am most willing to say something strong, because it is the thing I did not expect. This is genuinely a new way to think, not just a new way to type. You are scaling your own cognition. And the limit is no longer how fast your hands move or how many hours you have. The limit is how much clear intent you can hold at one time. That is a cognitive limit, not a physical one, and it is trainable in a way that typing speed never really was.

I keep coming back to the [Iron Man suit](/2026/06/03/agent-mode-iron-man-suit/) as the closest honest image, because the suit never replaced the man inside it. It amplified him. Without the man it is an empty shell, and without the suit the man is just very smart in a cave. The whole point is the pairing. And the suit does not make Tony Stark a faster typist. It makes his intent reach further. He decides where to go, and the machine handles the flying. What changes is not the speed of his hands. It is the radius of what one person can affect, and the radius is set by the clarity of the person at the center.

## The proof is the range

Here is the evidence, and it is not a benchmark. Over the last year I shipped four open-source projects, each in a different domain. A library of small playable games. A music synthesis engine built from raw arrays of numbers, with no samples. An animation studio that runs from scripts. A language-learning system that is nothing but text files and prompts. Different fields, different skills, none of which I am formally trained in across the board, all built primarily in agent mode, and all shipping things you can actually use today.

A few years ago that range would have been impossible for one person in a year. Not because the individual pieces are beyond a determined builder, but because the cost of becoming fluent enough in four unfamiliar domains to produce finished work in each one was too high. The typing alone would have eaten the year. What collapsed that cost was not that the agent knew those domains for me. It was that the agent handled the translation in each one, the part where you turn a clear intent into the specific incantation that a synthesizer or an animation pipeline or a spaced-repetition system wants. So my actual job in all four was the same job: decide what should exist, set the constraint, and verify the result.

That sameness is the tell. When the unit of thought is the keystroke, every new domain is a new language you have to learn before you can say anything in it. When the unit of thought is the intent, the domains start to rhyme, because the thing you are doing, holding a clear specification and checking it honestly, does not change when the subject does. The skill that scales is not domain knowledge. It is the discipline of clear intent, and that discipline ports.

I do not think this means anyone can now do anything. Taste does not transfer for free, and a clear head in one domain is not automatically a clear head in another. But the friction that used to keep a single builder pinned to one specialty got much thinner, and what is left holding you is your own judgment, spread as wide as you can keep it coherent. The four projects, and the one philosophy underneath them, are written up [together](/projects/) if you want the longer look.

## Judgment becomes the whole job

I want to be careful here, because the same thing that makes the suit powerful is exactly how you fly it into a mountain.

It does what you point it at, fast, and confidently, and that is precisely the danger. A vague intent gets you a polished version of the wrong thing. A weak check lets a plausible mistake through at speed. The faster the system, the more your judgment is the only thing standing between you and a very efficient disaster. Power that does what you say is only as good as the clarity of what you say and the rigor of how you confirm what came back.

I learned this in the most direct way possible. An agent wrote a deploy script for this site. It was a good script. It built the site, synced the files to S3, and cleaned up anything stale so the live bucket matched the build exactly. That last behavior, deleting whatever was not in the new build, is correct right up until the build comes up short. One day a build failed partway through and produced an incomplete set of files, and the script did exactly what it had been told: it made the live site match the incomplete build, which meant deleting most of the images from production.

Nothing about that was the agent being stupid. The script was logical. The bug was that a destructive operation had been coupled to an assumption that the build was always complete, and nobody, human or machine, had questioned that assumption until it failed.

The recovery is the point. The images were never really lost, because the source of truth was the repository on my machine, not the bucket. I pushed them back with a sync that only adds and never deletes, cleared the cache, and the site was whole again in a few minutes. Then I did the thing the incident was actually asking for. I changed the deploy so a bad build can no longer reach a destructive step, and so asset uploads only ever add. The failure became a permanent improvement to the system, which is the only good thing a failure is for.

That is the loop working as intended. Trust it to do the work. Do not trust it to be right. Keep a source of truth it cannot touch, and keep the irreversible operations behind a gate. The agent did most of the typing for the original script, the recovery, and the hardening. The judgment about how it should fail was mine, and it had to be, because that is the kind of decision that does not survive being delegated.

## What this asks of you

If the production stops being the constraint, the constraint becomes you, and not in a way you can fake.

You have to actually know what you want. Agent mode is brutal about this. When my intent is clear, the work pours out and most of it is right. When my intent is muddy, the work pours out just as fast and most of it is subtly wrong, and I have to throw it away and figure out what I was actually after, which I should have done first. The tool will not do that part. If the problem is still fuzzy in your own head, no amount of delegation helps, because you cannot specify what you have not figured out. That part is still yours, and it is more exposed than it used to be, because there is nowhere to hide it. You cannot disappear into an afternoon of typing and feel productive while you avoid the hard decision. The typing is gone. The decision is all that is left.

So the discipline did not go away. It moved, and it concentrated. I spend less effort making the thing and far more effort being sure I asked for the right thing and that the thing is correct. I think in failure modes now, because the platform keeps teaching me to: assume the part will fail, name how, and build so that when it does you already know what happens next. I think in specifications, because a specification is just intent made precise enough to act on. I think in verification, because speed without checking is just a faster way to be wrong. None of those are new ideas in engineering. What is new is that they are no longer the parts you get to around to. They are the parts that are left.

There is a version of this that reads as loss, as if the craft got hollowed out. I do not experience it that way at all. The typing was never the craft. The craft was always the judgment, the taste, the decision about what is worth building and the eye for when something that looks right is wrong. Agent mode did not remove the craft. It removed everything around the craft, and left me standing in front of the part that was always the point, with my whole attention free to spend there. This is the same instinct I bring to everything else I build, the discipline of [making a complex system legible enough to live inside](/coherent-complexity/), whether the system is a cloud platform, a codebase, or a life.

## Where it leaves you

The gap between having an idea and having the thing got small. A single builder with taste and a clear head can now reach a scale that used to require a team, and can keep the whole thing coherent because it is still one mind directing it. That is the part that feels new and a little vertiginous: the reach went up, and the thing that sets the reach is no longer your hands. It is the clarity you can hold.

So the practical advice is almost philosophical. Get clear. Learn to say what you want with enough precision that another intelligence can act on it without you hovering. Learn to verify without flinching, especially when the output looks finished. Learn to hold more than one thread without losing the shape of the whole. Those are the skills that scale now, and they are skills of thought, not skills of typing.

If you want the method I run inside all of this, I wrote down [an AI agent workflow that holds up](/2026/06/02/ai-agent-workflow-for-software-engineers/), and the book-length version is [AgentSpek](/books/agentspek/), free to read here in full. If you want the feel of the work rather than the mechanics, it is [not vibe coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/). And the rest of how I build this way lives at [AI-Assisted Development](/ai-development/).

The suit is real. It fits. And the strange, good catch is that it makes the human inside it matter more, not less, because the one thing it cannot do, decide what is worth building and know when it is right, is suddenly the only thing left to do.]]></content:encoded>
      <pubDate>Fri, 05 Jun 2026 20:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/05/agent-mode-changes-the-shape-of-thought/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/agent-mode-changes-the-shape-of-thought-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>ATTENTION IS THE LOOM: a beat-locked Alan Watts rap where the loom does the dancing</title>
      <link>https://joshuaayson.com/2026/06/05/attention-is-the-loom/</link>
      <description>ATTENTION IS THE LOOM is Song 06 in Out of Your Mind, the Napkin Films series built from the Alan Watts lectures. It is the one about attention: what you attend to becomes the cloth, and the rest falls through. The front and the back of the embroidery are both true, and the gap is the rhythm. This pass rebuilt the motion from scratch so the loom actually weaves and the camera dives through the cloth to its knotted back. CC BY 4.0.</description>
      <content:encoded><![CDATA[The last one was about the thread and the cloth. This one is about the eye that picks the thread.

ATTENTION IS THE LOOM is Song 06 in Out of Your Mind. The idea is simple and slippery. You do not see the world. You select it. Out of an ocean of signal you keep a thread here, a thread there, and the cloth that comes out the other side is the day you remember. What you ignore shapes you as much as what you keep, because it is the part that fell through. Watts had a second image stacked on the first: turn the embroidery over. The front is the neat picture you show. The back is the knots, the shortcuts, the threads carried from one place to another. And the back is the truth of the front. The rascal and the saint are the same person, seen from the two sides of one cloth.

Front side. Back side. Both are true.

## The motion is the idea

The first version of this film stood a bunny next to a still picture of some stitching and let it bob. It was the weakest of the series, and it taught the lesson the whole series needed: each film should not just look different, it should MOVE different. So I rebuilt it around a real loom.

There is a warp now, real vertical threads. A cloth that grows up the warp as the song runs. A shuttle that flies left and right once per bar, laying a new row each pass. A beater that drops on the downbeat and packs the row home. The bunny works it. The whole film has a pulse you can see, and it is the pulse of weaving.

## A camera that goes through the cloth

The camera stopped being a slow zoom. It follows the shuttle with a small sway, then at the chorus it dives straight into the weave and comes out the other side, on the knotted back, with a tilt as it passes through. In the bridge, the gap, it holds dead still. At the drop it splits the frame: the orderly front on one side, the knotted back on the other, the bunny standing on the seam between them. Two faces, one cloth.

## The loom is the band

It rides on a two voice Bach invention, recomposed in ChipForge, our engine that is just numpy and math, no GPU and no samples. The right hand is the front voice. The left hand and a harpsichord a bar behind are the back voice. Two lines, two sides, one cloth. And this time the loom itself plays: a shuttle clack on every beat, panned left and right so you hear it cross, a beater thump on the downbeat, a heartbeat inside the gap. The machine is the percussion.

The governor carries the words in English and German. The Plan 9 Glenda bunny answers from the back of the cloth. I am the back. Still you. Knots and all. Under it all, the motif: Vorderseite, Rueckseite. Front side, back side.

## Look closely

Napkin Films hides things. There is a constellation woven into the front of the cloth, the People of the Stars, faint until the drop. There is an AW tied into the knots on the back. There is a P9 thread in the corner of the loom. And there is one thread that runs off the right edge of the frame with a small star where it leaves, because the thread does not stop at the end of this film. That last one is a wink at what is coming.

## Made on a laptop

Stick figures in Python and PIL. A Bach invention in numpy. A loom animated by hand. A voice cloned into a Bavarian philosopher and a cyborg bunny. No GPU. No samples. No stock anything. Written, directed, composed, animated, voiced, and produced by me, with AI doing the parts I pointed it at.

It wraps in the house bookends. A mind bell opens it and resolves it. A card sketched on a napkin. And the governor's goodbye in his own tongue. Pfiat di, kleiner Weber. Farewell, little weaver.

## Watch it

[Watch ATTENTION IS THE LOOM on YouTube](https://youtu.be/jxUK2gSOP8A), part of the [Out of Your Mind playlist](https://www.youtube.com/@organicartsllc). The audio lives on [Bandcamp](https://organicartsllc.bandcamp.com).

## License

The film is CC BY 4.0. Remix it, repost it, drop it into your own thing. Credit Napkin Films / Organic Arts LLC and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

The engine code, Napkin Films and ChipForge, is GPL-3.0-or-later.

The music is an original ChipForge arrangement inspired by the public domain works of J.S. Bach. The source was studied for structure only. No audio was sampled and no melody was quoted. The words are adapted and compressed from Alan Watts, Out of Your Mind, not the original recordings. The ElevenLabs voice audio is licensed content and is not redistributed outside the film.]]></content:encoded>
      <pubDate>Fri, 05 Jun 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/05/attention-is-the-loom/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/attention-is-the-loom-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>THE WEB: a beat-locked Alan Watts rap on the day you found out you are the web</title>
      <link>https://joshuaayson.com/2026/06/04/the-web/</link>
      <description>THE WEB is Song 05 in Out of Your Mind, the Napkin Films series built from the Alan Watts lectures. It is the one about relationship: nothing stands alone, the figure is held up by the ground, and the dewdrop net reflects itself forever. A Bavarian governor voice raps it over a Bach Brandenburg canon, a web of voices that imitate and pull on each other, while a Plan 9 mirror-bunny answers from the other end of the loom. CC BY 4.0.</description>
      <content:encoded><![CDATA[The last one was about the player and the part. This one is about the thread and the cloth.

THE WEB is Song 05 in Out of Your Mind. The idea is the one Watts kept circling. Nothing stands on its own. A figure needs a ground. A line needs a page. A self needs an other. Things do not exist first and then connect. They exist only as the connecting. He called it mutual arising, and his picture for it was the dewdrop net. A spider web covered in dew, and every drop holds the reflection of every other drop, and inside each reflection, the reflection of all the rest.

Pull one thread and the whole cloth bonds. The room is the loom. You are sitting inside the cloth you thought you wove.

## The music is the idea

If the song is about interconnection, the music had to be interconnection you can hear. So I built it as a canon. A theme starts on the piano. A bar later a harpsichord enters playing the same theme, but bent to fit the chord that is happening now. Then a string section threads underneath. The lines imitate each other and lean on each other, and if you pull one, the others move. In the intro the voices come in one at a time, so you hear the web weave itself.

It rides on a Bach Brandenburg interplay, recomposed in ChipForge, our own engine that is just numpy and math, no GPU and no samples. Under the canon there is a real EDM rhythm section now: a driving kit, builds, crash hits, a rolling bass. Classical counterpoint on top, a beat underneath. That is the whole series in one sentence.

## Two bunnies, one thread

The governor carries the philosophy. But this film has always drawn two bunnies, one at each end of the loom, the second one lagging the first by half a bar like a canon made visible. This time the second one talks. It is the Plan 9 Glenda bunny, and it is the mirror that proves the point. The governor lays down a line and the mirror answers from across the loom. I felt that. Touched you. We are one thread. It is all me.

And under all of it, in German, the thing the whole song is saying: alles hängt zusammen. Everything is connected.

## Made on a laptop

Stick figures in Python. A Bach canon in numpy. A voice cloned into a Bavarian philosopher and a cyborg bunny. No GPU. No samples. No stock anything. Written, directed, composed, animated, voiced, and produced by me, with AI doing the parts I pointed it at.

It wraps in the house bookends. A mind bell opens it and resolves it. A card sketched on a napkin. And the governor's goodbye in his own tongue. Bis bald, kleiner Knoten. See you soon, little knot.

## Watch it

[Watch THE WEB on YouTube](https://youtu.be/s-Fc-Ctop2U), part of the [Out of Your Mind playlist](https://www.youtube.com/@organicartsllc). The audio lives on [Bandcamp](https://organicartsllc.bandcamp.com).

## License

The film is CC BY 4.0. Remix it, repost it, drop it into your own thing. Credit Napkin Films / Organic Arts LLC and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

The engine code, Napkin Films and ChipForge, is GPL-3.0-or-later.

The music is an original ChipForge arrangement inspired by the public domain works of J.S. Bach. The source was studied for structure only. No audio was sampled and no melody was quoted. The words are adapted and compressed from Alan Watts, Out of Your Mind, not the original recordings. The ElevenLabs voice audio is licensed content and is not redistributed outside the film.]]></content:encoded>
      <pubDate>Thu, 04 Jun 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/04/the-web/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/the-web-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Microservices, Agents, and What I Am Building Next</title>
      <link>https://joshuaayson.com/2026/06/03/microservices-agents-what-im-building-next/</link>
      <description>Microservices used to be a tax a solo builder could not afford. AI agents change that math. Here is why I am drawn to the architecture for what I build next, and the discipline that keeps it from becoming a mess.</description>
      <content:encoded><![CDATA[For most of my career, microservices were a tax I could not afford alone. The idea is good: break a system into small, independent services, each owning one job, each able to fail, scale, and change without dragging the rest down with it. The problem was the overhead. More services means more deployments, more boundaries to define, more wiring, more ways for the connections between things to break. For a small team or a solo builder, the cost of all that machinery usually outweighed the benefit, and the honest answer was to keep things in one well-organized monolith and not pretend otherwise.

AI agents change that math, and that is why the architecture is back on my mind for what I build next.

## What the agents change

The tax on microservices was never really the services. It was the connective tissue: the boilerplate, the deployment pipelines, the glue code, the operational babysitting of a dozen small things instead of one big one. That is exactly the kind of work the cost of which has collapsed. An agent can stand up a service, wire its deployment, write its tests, and connect it to the rest, in the time it used to take to decide whether the effort was worth it.

When the overhead per service drops far enough, the calculus flips. The reasons to want small, independent, isolated services were always sound. It was only ever the price that made them impractical at small scale. Lower the price and a single builder can run an architecture that used to require a platform team.

There is a deeper fit, too. A microservice is, by design, a bounded piece of work small enough to hold in one head. That is also the size of work an agent handles best. An architecture made of small, clearly-bounded units is an architecture you can hand to agents one unit at a time, which means the way I want to build and the way I want to structure what I build are starting to point in the same direction.

## Why it fits how I already think

This is not a new instinct dressed in new clothes. It is the same idea I keep circling in everything else.

Breaking a system into bounded services is one more way of making a complex thing [legible instead of simple](/coherent-complexity/). You do not pretend the system is small. You give it seams, so a human, or an agent, can reason about one part without holding all of it at once. The whole stays complex; each piece becomes comprehensible. That is the entire move I care about, applied to architecture.

It is also [antifragile](/2026/05/30/living-with-antifragility/) by construction. Isolation means a failure in one service is contained instead of cascading. Redundancy and independent scaling mean the system can absorb a shock in one place and keep running everywhere else. The same logic that makes me hold slack in a portfolio and redundancy in infrastructure makes me want boundaries in a system: not to be efficient, but to survive the part that breaks.

## The discipline that keeps it honest

Here is the catch, and it is the same catch as always. The fact that agents make microservices cheap does not make microservices free, and it absolutely does not make them always correct.

There is a failure mode where you decompose a thing into twenty services because you can, and you end up with distributed complexity that is harder to reason about than the monolith you started with. A poorly drawn boundary is worse than no boundary. Splitting a system along the wrong seams gives you all the overhead of distribution with none of the benefit, and now the mess is spread across a network instead of contained in one codebase.

So the rule I am holding onto is the same one I apply to money and to systems generally: robustness before optimization. Start with the simplest thing that works, usually one service, and split only when a real seam reveals itself, when a part genuinely wants to fail, scale, or change on its own schedule. Let the architecture earn its complexity. Do not reach for the sophisticated structure because the tools finally let you. Reach for it when the system is actually asking for it, and not one service before.

## What this means for what I build

The practical upshot is that the things I make next, the apps and tools and environments I have been sketching, get to be designed the way I always wanted them designed, in small honest pieces, because the help is finally good enough to make that practical for one person. I get to keep pushing the limits of what a single builder can stand up, using AI as additional hands, and keep the result coherent because each piece is small enough to understand and the seams between them are drawn on purpose.

That is the whole bet I keep making, in one more domain. Not simpler. Legible. A complex system, built in pieces you can actually reason about, that survives the failure of any one of them, and that one person can now hold in their head because they had the help to give it the right shape.

If you want the method underneath the building, it is [an AI agent workflow that holds up](/2026/06/02/ai-agent-workflow-for-software-engineers/). For the idea underneath the architecture, it is all the same thing: [coherent complexity](/coherent-complexity/).]]></content:encoded>
      <pubDate>Wed, 03 Jun 2026 19:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/03/microservices-agents-what-im-building-next/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/microservices-agents-what-im-building-next.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Agent Mode Feels Like the Iron Man Suit</title>
      <link>https://joshuaayson.com/2026/06/03/agent-mode-iron-man-suit/</link>
      <description>The suit never replaced Tony Stark. It amplified him. That is the closest thing I have to a description of what it feels like to build software in agent mode, directing one or many agents and scaling your own thought and output.</description>
      <content:encoded><![CDATA[The thing about the Iron Man suit is that it never replaced Tony Stark. It amplified him. Without the man inside it the suit is an empty shell, and without the suit the man is just very smart in a cave. The whole point is the pairing. That is the closest thing I have to an honest description of what it feels like to build software in agent mode, and I have been chasing a better metaphor for months without finding one.

I dreamt of this, frankly, for a long time before it arrived. Not the specifics. The feeling. The sense that the distance between having an idea and having the thing could collapse, that a single person with enough clarity could reach further than a single person ever has. It is here now, and it has exceeded what I let myself expect.

## What the suit actually amplifies

It is easy to assume the amplification is speed, that the suit just lets you type faster. That is the shallow version and it misses the real thing. The suit does not make you a faster typist. It makes your intent reach further. You decide where to go, and the machine handles the flying.

In practice that means I am no longer working at the level of the keystroke or even the function. I am working at the level of the task, and increasingly at the level of several tasks at once. I describe what I want built, the agent goes and builds it across the whole codebase, runs it, reads the failures, fixes them, and comes back. My attention sits where it is actually worth something: on what to build, on whether the result is right, on the decisions that compound.

The cost of producing the work dropped toward nothing. What is left is the part that was always the real job, and it turns out there is a lot of it.

## Scaling thought, not just output

The part that still surprises me is what happens when it is not one agent but several. You stop being a person who does one thing at a time and start being something closer to a conductor. One agent is refactoring a module while another is drafting a migration while a third is checking a result. You are holding more in flight than a single human working alone could hold, and the holding is the skill.

This is where the suit metaphor strains in a good way, because it stops being about a single exosuit and becomes about commanding a small fleet. The bottleneck moves off your hands and onto your ability to keep several streams coherent in your head, to know which one needs you now, to catch the one that is confidently heading the wrong direction. It is genuinely a new way to think, not just a new way to type. You are scaling your own cognition, and the limit is how much intent you can keep clear at once.

## Someone still has to fly it

I want to be careful here, because the suit is also exactly how you fly into a mountain.

It does what you point it at, fast, and confidently, and that is precisely the danger. A vague intent gets you a polished version of the wrong thing. A weak check lets a plausible mistake through at speed. The faster the suit, the more your judgment is the thing standing between you and a very efficient disaster. Power that does what you say is only as good as the clarity of what you say and the rigor of how you verify what came back.

So the discipline did not go away. It moved. I spend less effort making the thing and more effort being sure I asked for the right thing and that the thing is actually correct. That is not a downgrade. That is the work arriving at the place where a human is genuinely irreplaceable, and being freed to spend its whole attention there.

## The most alive I have felt building

I am aware this can read as hype, so let me just say the plain version. This is the most exciting time of my life to be alive and making things. Not because the tools are impressive, though they are, but because of what they do to the gap between a person and what that person can build. The gap got small. A single builder with taste and judgment and a clear head can now reach the scale that used to require a team, and can keep the whole thing coherent because it is still one mind directing it.

The suit is real. It fits. And the strange, wonderful catch is that it makes the human inside it matter more, not less, because everything it cannot do, deciding what is worth building and knowing when it is right, is suddenly the only thing left to do.

If you want the method I run inside the suit, it is [an AI agent workflow that holds up](/2026/06/02/ai-agent-workflow-for-software-engineers/), and the book-length version is [AgentSpek](/books/agentspek/), free here. For how I keep the whole expanding system legible instead of overwhelming, that is the larger idea: [coherent complexity](/coherent-complexity/).]]></content:encoded>
      <pubDate>Wed, 03 Jun 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/03/agent-mode-iron-man-suit/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/agent-mode-iron-man-suit.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>THE GAME INSIDE: a beat-locked Alan Watts rap on the cosmic game of hide and seek</title>
      <link>https://joshuaayson.com/2026/06/03/the-game-inside/</link>
      <description>THE GAME INSIDE is Song 04 in Out of Your Mind, the Napkin Films series built from the Alan Watts lectures. It is the one about the game of hide and seek that consciousness plays with itself. Life is a play. The central self is playing every part. The only rule is to forget you set it up. A Bavarian governor voice raps it over Bach&apos;s Goldberg Variations re-composed into G major EDM, and the Plan 9 bunny answers back as the player who keeps finding him. CC BY 4.0.</description>
      <content:encoded><![CDATA[The menu one was about the symbol eating the thing. This one is about the player forgetting the part.

THE GAME INSIDE is Song 04 in Out of Your Mind. The idea is the oldest one Watts kept coming back to. Life is a play. There is one central self, and it is playing every part of every being everywhere. The only rule of the game is that it forgets it set the whole thing up. It plays hide and seek with itself. It gets lost on purpose, so it can find its way back out.

Person means mask. Per sona. The sound that comes through. You drew a face and walked through the door. You played the part and forgot the score. The role got so real the actor got lost in it. That is not a bug. That is the game.

## The hook

The old cut opened slow. A pretty Aria, thirty seconds of throat clearing before anything happened. So I cut a cold open. The first thing you hear is the governor spitting the hook over a single stab. You're it. You're it. Come out, come out. You're it. Then the beat drops and the bunny walks on.

That is the whole film in four words. You're it. You were always it.

## Two voices now

The governor carries the philosophy. Dry in the verses, lifting on the hooks, German underneath. But this time he is not alone on stage. The Plan 9 bunny answers him. Its own voice. The playful one, the kid who is winning the game. He lays down a bar and she peeks out from behind the mask. Found you. Peekaboo. Hi. It's me. It was always me. You're it.

That call and response is the point. The serious voice keeps explaining the game. The little voice keeps proving it. Some of the governor's lines are lifted straight from the lecture. You are all of it. You are only pretending you are not.

## The score is the idea

I did not pick the Goldberg Variations because they sound nice over a beat. I picked them because they are the same idea in music. One theme, hidden through thirty disguises, always almost coming home. That is hide and seek written for a harpsichord in 1741.

So ChipForge builds on the real Goldberg ground bass. The descending line that holds up all thirty variations. G, F sharp, E, D, down and around and home to G. An Aria rides on top on a soft harpsichord. Then the sections turn it the way Bach turned it. Ornament it. Invert it. Drop it into G minor for the bridge where the player gets lost. Bloom it back to G major for the sun.

Every note is locked to the key. The engine snaps it in tune as the last step, so nothing wanders off. A canon voice answers the theme a beat late. A string section fills the room. It is fuller than anything I have made, and it is still just sine waves and math on a laptop.

## The stage got real

The first passes were a stick figure standing in one spot. Boring. So I gave the bunny a stage to work. A spotlight cone falls from the flies and follows it as it walks the boards. There are footlights and a floor that runs back to a vanishing point. It wears a king's mask, lifts it, and there is another bunny in another mask. Six masks pass in turn, and each one lifts on the word. Lift the king, find the child. The mask changes exactly when he says it does.

Then the curtains pull back and there is the sun, and the bunny is holding it.

## Made on a laptop

Stick figures in Python. Music in numpy. A voice cloned into a Bavarian philosopher and a cyborg bunny. No GPU. No samples. No stock anything. Written, directed, composed, animated, voiced, and produced by me, with AI doing the parts I pointed it at.

It wraps in the house bookends. A mind bell opens it and resolves it. A card sketched on a napkin. And the governor's tongue in cheek goodbye in his own Bavarian. Pfiat di, Spieler. Be well, player.

## Watch it

[Watch THE GAME INSIDE on YouTube](https://youtu.be/kHYQF7LzLwM), part of the [Out of Your Mind playlist](https://www.youtube.com/@organicartsllc). The audio lives on [Bandcamp](https://organicartsllc.bandcamp.com).

## License

The film is CC BY 4.0. Remix it, repost it, drop it into your own thing. Credit Napkin Films / Organic Arts LLC and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

The engine code, Napkin Films and ChipForge, is GPL-3.0-or-later.

The music is an original ChipForge arrangement of a public domain work, J.S. Bach's Goldberg Variations, BWV 988. The source was studied for structure only. No audio was sampled and no melody was quoted. The words are adapted and compressed from Alan Watts, Out of Your Mind, not the original recordings. The ElevenLabs voice audio is licensed content and is not redistributed outside the film.]]></content:encoded>
      <pubDate>Wed, 03 Jun 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/03/the-game-inside/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/the-game-inside-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>I Rebuilt This Whole Site in Agent Mode</title>
      <link>https://joshuaayson.com/2026/06/03/rebuilt-my-site-in-agent-mode/</link>
      <description>This site was rebuilt from scratch by directing an AI agent, then migrated off cPanel onto AWS S3 and CloudFront. Here is what that actually looked like, the parts that worked, and the day a deploy script quietly deleted production.</description>
      <content:encoded><![CDATA[The site you are reading was rebuilt from scratch by directing an AI agent, and then moved off shared hosting onto AWS. I did not type most of it. I directed it. That distinction is the whole story, so let me be concrete about what it actually looked like, because the honest version is more useful than the brochure.

## The starting point was WordPress on cPanel

Before this, the site was WordPress on cPanel, the way a lot of personal sites are. It worked, in the sense that it was up. It was also slow, heavy, a moving target for security updates, and a place where every change meant fighting a theme and a stack of plugins to do something a flat file could do better. I wanted a static site: plain HTML and CSS served fast, with the content living as files I own instead of rows in a database I have to babysit.

So the goal was two things at once. Rebuild the site on a modern static stack, and migrate the hosting off cPanel and onto AWS. Either one is a project. Doing both, solo, would have been a month of evenings a couple of years ago. It was not.

## What "agent mode" actually meant here

Agent mode is letting the AI do the task, not the keystroke. I did not ask it to write a function. I handed it the codebase and a destination: build this in Astro, keep the content as markdown, make it fast, match this design sense. Then it read the existing structure, made changes across many files at once, ran the build, read the errors, and fixed them, and surfaced when it was stuck or when a real decision was mine to make.

My job moved up a level. I was not writing the components. I was deciding what the site should be, reviewing the diffs, catching the architectural choices that would cost me later, and saying yes or no. The cost of producing the code dropped close to zero. The thing that did not drop, the thing that became more important, was judgment: knowing what to build, and knowing when the agent had done something that looked right and was wrong.

That is the part the hype skips. Working this way is not less engineering. It is more of the engineering that matters and less of the typing that does not.

## The migration, and the antifragile habit

Moving from cPanel to AWS meant rebuilding the serving layer too: the site is now static files in an S3 bucket, served through a CloudFront distribution, with the caching and the redirects and the security headers all defined as configuration instead of clicked into a control panel. The agent did the bulk of the wiring. I did the part you cannot delegate, which was deciding how it should fail.

That phrase matters more than it sounds. The move taught me as much as it migrated. Doing it well meant naming the failure modes in advance and rehearsing them, instead of discovering them in production. What happens when a deploy is incomplete. What happens when a cache header is wrong. What happens when a path that worked on the old host does not resolve the same way on the new one. The platform itself kept nudging me toward the same habit: assume the part will fail, and build so that when it does, you already know what happens next.

## The day a deploy script deleted production

Here is the part I want to keep in, because it is the real lesson and not the marketing one.

An agent wrote a deploy script. It was good. It built the site, synced the files to S3, and cleaned up anything stale so the bucket matched the build exactly. That last behavior, deleting whatever was not in the new build, is correct right up until the build comes up short. One day a build failed partway through, produced an incomplete set of files, and the script did exactly what it was told: it made the live site match the incomplete build, which meant deleting most of the images from production.

Nothing about that was the agent being dumb. The script was logical. The bug was that a destructive operation was coupled to an assumption that the build was always complete, and nobody, human or machine, had questioned that assumption until it failed.

The recovery is the point. The images were never really lost, because the source of truth was the repository on my machine, not the bucket. I pushed them back up with a sync that only adds and never deletes, cleared the cache, and the site was whole again in a few minutes. Then I did the thing the incident was actually asking for: I changed the deploy so a bad build can no longer reach a destructive step, and so asset uploads only ever add. The failure became a permanent improvement to the system, which is the only good thing a failure is for.

I caught it, fixed it, and hardened it, and the agent did most of the typing for all three. That is the loop working as intended. Trust it to do the work. Do not trust it to be right. Keep a source of truth it cannot touch, and keep the irreversible operations behind a gate.

## It is still changing

The site is not finished, and I do not want it to be. It is a place I keep rebuilding in the open, because the tools keep getting better and because the practice of working this way is itself the thing I am trying to learn. What used to be a month of evenings is now an afternoon, and the bottleneck has moved entirely to taste and intent and verification, which is exactly where I want it.

If you want the method underneath this, I wrote it down: [an AI agent workflow that actually holds up](/2026/06/02/ai-agent-workflow-for-software-engineers/), and the longer version in [AgentSpek](/books/agentspek/), free to read here. And if you want the philosophy underneath the method, it is all one idea: [making a complex system legible enough to live inside](/coherent-complexity/), whether the system is a cloud platform, a codebase, or a life.]]></content:encoded>
      <pubDate>Wed, 03 Jun 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/03/rebuilt-my-site-in-agent-mode/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/rebuilt-my-site-in-agent-mode.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>ATE THE MENU: a beat-locked Alan Watts rap on the day the map ate the land</title>
      <link>https://joshuaayson.com/2026/06/02/ate-the-menu/</link>
      <description>ATE THE MENU is Song 03 in Out of Your Mind, the Napkin Films series built from the Alan Watts lectures. It is the one about symbols eating the substance they point at. The map became the territory. The page outranks the place. You wheel a cart of real food to the counter and grieve the thirty dollars of paper instead of the gold you are carrying home. A Bavarian governor voice raps it over Mussorgsky&apos;s Promenade re-composed into D minor EDM, with a German echo underneath. CC BY 4.0.</description>
      <content:encoded><![CDATA[# ATE THE MENU: a beat-locked Alan Watts rap on the day the map ate the land

[Watch on YouTube](https://youtu.be/xc70zzSbBBg). Song 03 in Out of Your Mind, the series built from the Alan Watts lectures. This is the one about symbols eating the substance they were supposed to point at. The menu is not the meal. But you ate the menu.

Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## The idea

A menu describes food. A map describes land. A price tag describes worth. None of them are the thing. They are pointers, and the deal works only as long as everyone remembers which is which. Watts' joke is that we forgot. The map became the territory overnight. You walk the paper and forget the land. You learn the name and forget the thing. The label sits where the substance stood.

His sharpest version is the supermarket. You wheel a whole cart of real food to the counter. The tape spits out a number. You hand back thirty dollars of paper, and you feel the loss, the pinch, the small grief. For the paper. You are carrying home a cart of actual wealth and mourning the symbol you traded for it. The pinch is in the head. The wealth is in the cart.

> The page outranks the place it points at. Symbols charge you tax. Substance pays you back.

The lyric is not Watts verbatim. The concept is his. The words are the house voice, the same freewriting vocabulary the rest of these films draw on: line, scribe, page, gold, mined, mark. Watts gives the idea. Napkin Films gives the mouth.

## The voice, locked to the beat

It is rapped and narrated by Der Gouverneur, a Bavarian philosopher governor voice, an instant clone made with ElevenLabs. The delivery is a spoken-word spit-rap locked to the beat. Each line is time-stretched to a whole number of beats so the rhymes land on the grid, then pitch-tuned just enough to sing with the song while staying spoken word. The verses sit in the talking pocket, dry and a little comic, the way Watts told the supermarket story while grinning. The hooks lift and sing, anchored on the chorus and the drop. It is the same beat-lock approach used across the series, the blueprint set on [Ceramic](/2026/05/24/ceramic/).

## A second voice, in German

A German echo answers in the gaps, low and sung. Die Speisekarte ist nicht das Essen. The menu is not the meal. It comes back under the drop, doubled and harder: Die Speisekarte, nicht das Essen. Das Papier, nicht der Reichtum. The paper, not the wealth. Same singer, his mother tongue, woven in as a shadow layer rather than a translation.

## The score

The bed is Mussorgsky's Promenade, the walking theme from Pictures at an Exhibition, re-composed bar by bar into EDM in ChipForge, our own music engine (numpy synthesis, no samples). Seven sections of twelve bars each at 96 BPM, D minor throughout. The Promenade is the right source to steal the bones from: it is literally the music of a person walking between pictures, between representations of things. The whole film is about mistaking the representation for the thing, so the score walks you through a gallery of paper.

This cut rides an in-tune rework of that bed, with voice-led pads, a sub bloom on the chorus, and a vocal swell at each section entrance. The original v1 was a clean first draft. This is the enhanced pass, same beat-locked vocal, a better bed under it and a cinematic finish on top.

## The picture

The visuals tell the turn without a caption. A bunny holds a single menu card. The card unfolds into many. The cards stack into towers, and the bunny lifts a fork to the paper instead of the plate. A clerk rings up a cart at a register and a receipt tape begins to spool. The tape grows, then wraps the entire screen while menus rain down, the symbol eating the frame in real time. At the close the chaos resolves to a single line, not the meal, and the bunny puts down the fork. The palette runs from cold newsprint to warm faded paper. On top sits the series cinematic finish: a warm grade, a soft bloom that lifts at each section, film grain, and a chromatic shimmer pulsed on the kick through the drop.

## The bookends

Out of Your Mind house style. A mind-bell jingle opens at the top and resolves at the close, the sonic hook on every film in the series. A card sketched on a napkin. A goodbye in the film's own tongue. For this one the governor's Bavarian again, tongue in cheek: Tschuss, kleiner Spieler. Goodbye, little player.

## Made on a laptop

Stick-figure-simple visuals in Python and PIL at 854x480, a full EDM score from ChipForge, a beat-locked ElevenLabs rap in two languages, a series intro and outro, and the whole distribution package. All generated locally. No GPU, no subscriptions, no commercial loops.

## More from Napkin Films

If this one landed:

- [Ceramic](/2026/05/24/ceramic/), Song 01, the opener that set this house style, on whether you were made or grew.
- [The Automatic Dream](/2026/05/29/the-automatic-dream/), Song 02, on the inherited story that you are a machine.
- [The Keys to Power](/2026/05/22/the-keys-to-power/), the blueprint for the beat-locked, in-tune rap used here.
- [The Great Pretending](/2026/04/24/the-great-pretending/), the earlier Alan Watts cosmic meditation that pointed at this whole series.

More under the [Napkin Films](/tag/napkin-films/) tag.

## License

This film is licensed CC BY 4.0 (Creative Commons Attribution 4.0 International). Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

ElevenLabs voice audio is licensed content and is not redistributed outside of this film. The music is an original ChipForge arrangement of a public-domain work, Mussorgsky's Promenade from Pictures at an Exhibition (1874); the source was studied for structure only, no audio was sampled and no melody was quoted. The words are adapted and compressed from Alan Watts, Out of Your Mind, not the original recordings.]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/ate-the-menu/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/ate-the-menu-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>What Is Autonomous Mode? And When to Actually Trust It</title>
      <link>https://joshuaayson.com/2026/06/02/what-is-autonomous-mode/</link>
      <description>Autonomous mode is when the agent runs the whole loop without you in it: plan, act, check, repeat, until the task is done or it gets stuck. Here is what that means, how it differs from agent mode, and where the real risk lives.</description>
      <content:encoded><![CDATA[If [agent mode](/2026/06/02/what-is-agent-mode/) is you directing an AI through a task one step at a time, **autonomous mode is letting it run the whole loop without you in each step.** You give it a goal. It plans, acts, checks its own work, and repeats, until the task is done or it hits something it cannot get past. You come back to a result, not a series of approvals.

That is the promise. It is also where the term gets oversold, so let me be precise about what it actually is and where it actually works.

## The difference from agent mode is the leash

In agent mode you are in the loop. The agent makes a change, you review the diff, you send it again. There is a human checkpoint between each step.

In autonomous mode you move the checkpoint to the end. The agent runs many steps on its own: write the code, run the tests, read the failure, fix it, run again, and only surfaces when it finishes or gets stuck. The leash is longer. Sometimes there is no leash between start and finish at all.

The capability is the same underneath. What changes is how much you let it do before you look.

## Where it genuinely works

Autonomous mode shines on tasks that are **well-specified and cheaply verifiable**, where the agent can tell on its own whether it is making progress.

- Running a test suite to green: write, run, read the failure, fix, repeat. The tests are the judge.
- Mechanical migrations across many files where success is checkable.
- Long, boring loops you would never want to babysit: dependency bumps with a passing build as the gate, large-scale renames, format conversions.

The common thread is a tight, automatic feedback signal. When the agent has a reliable way to know "am I right yet," it can run the loop without you. When it does not, it wanders.

## Where the risk lives

The danger is not that the agent does nothing. It is that it does a lot, confidently, in the wrong direction, because nothing stopped it.

Two failure modes to respect. First, **a bad signal:** if the test it is optimizing toward is weak, it will happily satisfy the weak test and produce something wrong. Second, **blast radius:** an autonomous loop with the power to touch production, delete data, or push changes is a different risk class than one confined to a branch. The fix is not to avoid autonomy; it is to give autonomy a sandbox and a real verification signal, and to keep the irreversible actions behind a human.

## How to use it without getting burned

Start narrow. Let it run autonomously on things you can throw away or easily revert: a branch, a scratch environment, a test loop. Watch what it does over a few runs before you widen the leash. Keep the destructive, irreversible operations gated behind you no matter how good it gets. Autonomy is a dial, not a switch, and the skill is knowing how far to turn it for a given task.

I go deeper on all three modes, conversational, agent, and autonomous, in [AgentSpek](/books/agentspek/), free to read here. And if you want the everyday version, [an AI agent workflow that holds up](/2026/06/02/ai-agent-workflow-for-software-engineers/).]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 17:30:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/what-is-autonomous-mode/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/what-is-autonomous-mode.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>An AI Agent Workflow for Software Engineers That Actually Holds Up</title>
      <link>https://joshuaayson.com/2026/06/02/ai-agent-workflow-for-software-engineers/</link>
      <description>A practical, repeatable workflow for building software with an AI agent: specify, delegate, verify, record. The loop I actually run every day, with the parts that keep it from turning into slop.</description>
      <content:encoded><![CDATA[A lot of advice about working with AI agents stops at "just ask it to build the thing." That works for a demo and falls apart on a real codebase. Here is the workflow I actually run, day in and day out, on production systems.

It has four moves: **specify, delegate, verify, record.** None of them is glamorous. Together they are what separates agentic development from generating slop.

## 1. Specify before you delegate

The agent is only as good as the intent you hand it. Vague in, vague out. So the first move is not typing a prompt, it is getting clear on what you want.

For anything beyond a trivial change, I write the intent down: the outcome, the constraints, the parts that are non-negotiable. In a repo I keep a `CLAUDE.md` that tells the agent how this project works, what conventions to follow, and what not to touch. That file does more for output quality than any clever prompt, because it makes my standing intent permanent instead of repeating it every session.

## 2. Delegate the whole task, not the keystrokes

Once the intent is clear, hand the agent the *task*, not a line. "Add rate limiting to the payments endpoint and update the tests" is a task. Let it read the codebase, make the change across files, and run the suite. Resist the urge to micromanage the implementation. You set the destination; it drives.

This is where the speed comes from. The cost of writing the code drops to near zero. Your attention moves up a level.

## 3. Verify like you do not trust it

This is the step people skip, and it is the one that matters most. **AI-generated code can pass every test and still be wrong.** So verification is not a formality.

I read the diff. I run the tests. For infrastructure, I check the actual deployed behavior, not just that the command exited zero. When I moved a site to a private S3 origin recently, the agent's change was correct except for one thing it could not have known without checking: the new origin did not serve directory index files, so every subpage would have broken. I caught it because I verified the live behavior, not the build log. Trust the agent to do the work. Do not trust it to be right.

## 4. Record what you decided

The last move is the one that compounds. When you make a real decision, write down why. I use short architecture decision records for the project and a journal for my own process. It sounds like overhead. It is the opposite: it turns each session into something the next session, and the next agent, can build on instead of relearning.

## Why the loop holds

Specify, delegate, verify, record. The first and third steps are where your judgment lives, and they are exactly the steps an agent cannot do for you. That is the point. The workflow does not replace your engineering; it moves it to where it is worth the most, deciding what to build and confirming it is right, and hands the typing to the machine.

If you want the full version of this, I wrote [AgentSpek](/books/agentspek/), a book on building this way, free to read here. See also [what agent mode actually is](/2026/06/02/what-is-agent-mode/) and [AI-Assisted Development](/ai-development/) for how I apply it day to day.]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/ai-agent-workflow-for-software-engineers/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/ai-agent-workflow-for-software-engineers.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Making Complexity Visible: You Cannot Simplify the Ocean, Only Chart It</title>
      <link>https://joshuaayson.com/2026/06/02/making-complexity-visible/</link>
      <description>When a system gets too big to hold, almost everyone reaches for the same move: make it simpler. It is the wrong move. You cannot simplify the ocean. You can only chart it. This is about the difference between simplicity and legibility, why decisions quietly migrate to whoever holds the context, and how to make a complex system visible enough to navigate without pretending it is small.</description>
      <content:encoded><![CDATA[Here is the first move almost everyone makes when a system grows too big to hold. They try to make it simpler. Flatten it, hide it, wrap it, abstract it until it fits inside one tired head at the end of a long day.

I made that move for years. It is the wrong one, and understanding why it is wrong is the most useful thing I have learned about building anything large.

You cannot simplify the ocean. You can only chart it.

## Two Kinds of Complexity

Start with the honest part. Some complexity is junk. Fred Brooks called it accidental complexity back in 1986: the mess we make ourselves, the tangle that exists only because nobody cleaned it up. Dead code. A config that needs three files to say one thing. A process with a step that made sense in 2019 and survives out of pure habit. Cut all of that. Cut it without mercy. The world is better with less of it and you will never miss it.

But under the junk there is another kind, and Brooks named that one too. Essential complexity. The complexity that lives in the problem itself. A payment system is genuinely hard because money is genuinely hard. A distributed system is genuinely hard because the network genuinely lies to you. A family is genuinely complicated because people are. You cannot refactor that away. It is not a mess. It is the thing.

The mistake is treating the essential kind like the accidental kind. You keep reaching for the delete key on something that will not delete, and every time you fail you feel a little more like the problem is you. It is not you. You are trying to drain the sea with a cup.

The ocean does not get smaller because you wish it. It does not owe you a pond. So the real question stops being *how do I make this small enough to hold* and becomes something better: *how do I learn to see it whole without pretending it is small.*

That is legibility. And it is a different craft than simplicity entirely.

## A Chart Is Not a Smaller Ocean

A nautical chart does not shrink the sea. The water is exactly as deep, the rocks exactly as sharp, the storms exactly as indifferent as they were before anyone drew a line. What the chart changes is you. It lets one human being stand on a deck and hold a piece of the ocean in their mind, enough of it to make the next good decision, and the one after that.

Korzybski said the map is not the territory, and people usually quote him to warn you off the map. I read it the other way. Of course the map is not the territory. That is the whole point of the map. The territory is too much. The map is the part of the territory a human can carry.

Legibility is when a system shows you its own state before you have to go hunting for it. Not when you *can* answer a question about it if you know the question and where to dig. When you can glance and know. The distance between those two is the distance between querying the sea and reading it.

James Scott used the word legibility as a warning. He showed how states flatten messy living things into grids and ledgers so they can tax and control them, and how much gets destroyed in the flattening. He was right, and the danger is real, and it is the exact danger I am not talking about. The flattening he feared makes the territory legible to a distant ruler by killing whatever does not fit the grid. I mean the opposite motion. Legibility for the navigator, not the king. A chart you make so you can move through the thing wisely, not a grid you impose so you can pretend it is simpler than it is. The first keeps the danger on the page. The second paints over it.

## Where the Decisions Go

Here is what illegibility actually costs, and it is far more than slow work.

When a system is hard to see, decisions quietly migrate to whoever happens to hold the context. Not the right person. The legible-to person. The one who set it up, who remembers, who has the whole tangle loaded in their head because they have been carrying it for two years.

You have met this person on every team. They are the only one who really understands the deploy. The only one who knows why the numbers in that report never quite match. The only one who can say whether the system is actually healthy or just looks healthy from the outside. They are not hoarding anything. They simply *became* the map because no other map exists, and now the system cannot think without them. They cannot take a real vacation. The team's intelligence is bottlenecked on one person's memory and one person's availability.

Multiply that across a company and you get an organization whose real intelligence is far smaller than the sum of its people, because most of what it knows is trapped in a handful of heads, illegible to everyone else. The same thing happens to a household where one person holds the whole budget in their gut, or a project where the true status lives only in a lead's quiet anxiety. The state is real. It is just not visible. So the circle of people who can think well about it stays small, and stays tired.

Make the system legible and you widen that circle. That is the entire payoff. Not a prettier screen. A larger number of people who can hold the whole and reason about it. Coordination, stripped down to the bone, is mostly a group of people managing to look at the same picture at the same time.

## Giving the System a Face

So what do you actually build. You give the system a face.

I have spent a lot of years building these surfaces. Live views of systems that used to answer only to the person who built them. Maps of processes that used to live in somebody's head. Dashboards, when the word does not embarrass me, though the word undersells the thing. The idea underneath all of them is the same, and it is almost too simple to say out loud: stop making people query for state, and let the state be ambient.

Ambient is the key word. You want the state of the system to register the way it registers when a room goes quiet. Before you have consciously checked anything, before you have run a single query, you already feel that something is off. A good live view of a running system does that. You walk past it and your body knows the shape of the day. The knowledge stops being something you go and fetch and becomes something you simply have, the way you have the weather.

And the thing that changes when you build it well is never mostly technical. It is that people who do not own the system can suddenly tell when it is wrong. Conversations get shorter, because nobody has to reconstruct the picture before the real discussion can start. The thing becomes a shared object, and a shared object is half of what coordination even is. You did not make the system simpler. You made it legible, and legibility did the rest.

## Coherence Is Not Simplicity

This is the turn the whole essay has been walking toward, so let me say it plainly.

The goal is not a simple system. The goal is a coherent one.

Simplicity throws information away. Coherence keeps the information and arranges it so a human can hold it. A simple map of the ocean is a blue rectangle, and it will get you killed. A coherent chart has every rock and current and depth still on it, all the danger intact, organized so that a person on a moving deck can read it in the dark and live. Simplicity lies to make you comfortable. Coherence tells the truth in a shape you can use.

I have started calling the thing I am chasing *coherent complexity*. The state where a system stays as complex as it truly is, and stays understandable enough to navigate anyway. You do not pretend the sea is a pond. You become a navigator. That is the only honest relationship with anything genuinely hard, and once you have the phrase for it you start seeing it everywhere, or seeing its absence.

There is even a law for why simplicity fails here. Ashby, in early cybernetics, called it requisite variety: to control a system, your model of it has to be at least as rich as the system itself. Shrink your model below the complexity of the thing and you lose your grip on it. You cannot out-simple a complex world. You can only build a richer way of seeing it. The chart has to carry enough to match the sea. That is not bureaucracy. That is survival.

## The Same Move, Everywhere

Once you have the move, you cannot stop seeing it, and it stops being only an engineering trick.

A life is an illegible system. The state is real and it is smeared across your calendar, your body, your bank account, your relationships, your half-finished intentions, and almost none of it is visible at once. Most people run a life the way a tired team runs a system nobody charted: by holding it all in an anxious head and hoping. I keep my own time by the stars and the decans for exactly this reason. Not because the cosmos sends instructions, but because a slow steady cycle is a chart for a year, a way to make a long sprawling stretch of time legible enough to move through on purpose instead of drifting.

A family is an illegible system. A portfolio is an illegible system. A company is a thousand of them stacked on each other. The move is identical every time. Find the place where important state is real but invisible, and give it a single surface where a human can hold it whole. Cluster, release, codebase, quarter, marriage, life. Different oceans. The same craft of the chart.

## The Navigator's Art

So here is where I have ended up, after years of reaching for the delete key on things that refused to delete.

You do not conquer a complex system. You do not shrink it down to where it stops being itself. You learn to read it. You build the chart that lets a human stand in front of the whole moving thing and know, in seconds, where they are and what to do next. And then you hand the chart to the next person, and the next, until the knowledge that used to live in one exhausted head lives out in the open where anyone can use it.

The sea never gets smaller. That was never the deal. The deal is that you can become someone who reads it. A navigator is not braver than a drowning person. They can just see. That seeing is the whole of the freedom, and it is buildable, and building it is some of the best work there is.

That is what I mean by making complexity visible. Not making it simple. Making it legible enough to love.

Dip the oar. The other end rises. Reach for the next dip. Let's go.

---

## Related reading

- [DevOps Beyond Automation: What Compounds in a 15-Year Engineering Career](/2026/05/27/devops-beyond-automation/): the deeper goal under every tool I build: systems that change without breaking
- [Living with Antifragility: How I Build Systems and a Life That Gain from Disorder](/2026/05/30/living-with-antifragility/): why you keep the danger on the page instead of painting over it
- [AWS Is Math, Kubernetes Is Physics](/2026/05/31/aws-is-math-kubernetes-is-physics/): the grand and the granular, held in one view
- [What Is People of the Stars?](/2026/05/26/what-is-people-of-the-stars/): keeping time by the stars as a chart for a year

*Sources for the ideas borrowed here: Fred Brooks on essential versus accidental complexity (No Silver Bullet, 1986); Alfred Korzybski on the map and the territory (Science and Sanity, 1933); James C. Scott on legibility and the state (Seeing Like a State, 1998); W. Ross Ashby on requisite variety (An Introduction to Cybernetics, 1956).*]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/making-complexity-visible/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/making-complexity-visible.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Claude vs Copilot for DevOps: A Practitioner&apos;s Comparison</title>
      <link>https://joshuaayson.com/2026/06/02/claude-vs-copilot-for-devops/</link>
      <description>I used GitHub Copilot in VS Code for a long time, always with Claude underneath. Then I moved most of my work to Claude Code. Here is the honest comparison for DevOps and infrastructure work, from someone who ships with both.</description>
      <content:encoded><![CDATA[I used GitHub Copilot in VS Code for a long time, and for most of that time I had Claude running underneath it. Then I moved the bulk of my work to Claude Code. This is the comparison I wish I had read before I made that move, written for DevOps and infrastructure work specifically.

The short version: for line-by-line completion they are close, and for **agent mode**, the kind of work where you direct a model to change many files and verify itself, Claude Code has been the stronger tool for me. Here is why, with the parts that actually matter for infrastructure work.

## They are aiming at different jobs

GitHub Copilot started as an autocomplete and grew outward. Its center of gravity is still the editor: you are typing, it is suggesting. That is genuinely useful, and inside VS Code it is well integrated.

Claude Code starts from the other end. It is a terminal-native agent built to take a task, read the repository, make the change across files, run the commands, and report back. The editor is not the center; the task is.

For DevOps work that distinction is the whole game, because infrastructure changes are rarely one line in one file. A rate limit, a new origin, a CDK change, a CI pipeline edit, each of those touches several files and a test or a deploy. The tool that holds the *task* beats the tool that holds the *line*.

## Where each one wins

**Copilot wins** when you are heads-down writing code in the editor and want fast, low-friction completion. It is also the path of least resistance if your whole team already lives in VS Code and you want one consistent surface.

**Claude Code wins** when the unit of work is bigger than a function: a multi-file refactor, standing up infrastructure, wiring CI, migrating config across a repo. It reads the codebase as context, makes coordinated changes, and runs the verification step itself. For the way I work, that is most of the day.

## A concrete DevOps example

I recently moved a static site's CloudFront distribution to a private S3 origin behind an Origin Access Control, with a basic-auth gate at the edge. In Claude Code I described the end state. It changed the origin, wrote the bucket policy, attached the function, and flagged the gotcha that bites everyone on this setup: the S3 REST endpoint does not auto-serve directory index files the way the website endpoint does, so subpaths break unless you rewrite them. That is the kind of cross-file, knows-the-trap work where the agent earns its place.

Copilot would have helped me type each of those files faster. Claude Code did the task and showed me the diff.

## What I actually use

Both, honestly, but the balance has shifted hard toward Claude Code for anything bigger than a single edit. If you do DevOps and your work is mostly multi-file changes and infrastructure, that is the one I would start with. If you spend your day inside a single service writing functions, Copilot's editor integration is a real comfort.

If you want the longer argument for working this way, I wrote a book on it: [AgentSpek](/books/agentspek/), free to read here. For how it feels in practice, [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/), and for [what agent mode actually is](/2026/06/02/what-is-agent-mode/) if the term is still fuzzy.]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 16:30:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/claude-vs-copilot-for-devops/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/claude-vs-copilot-for-devops.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Run Your Life Like Software</title>
      <link>https://joshuaayson.com/2026/06/02/life-ops-running-your-life-like-software/</link>
      <description>Life Ops is running your life as a deliberate system, designed the way you design software: observe before acting, choose responses over reactions, build systems that make the good path the easy one, and version the whole thing like code.</description>
      <content:encoded><![CDATA[Life Ops is running your life as a deliberate system, designed the way you would design software. Not optimizing yourself into a machine, and not turning every morning into a dashboard. The opposite. It is building the smallest set of systems that make the good path the easy path, then versioning them like code: observe, choose, act, iterate.

I came to this the embarrassing way. I spend my days building and operating software systems, where I would never ship without a test, never deploy without a way to roll back, never let a recurring failure go un-investigated. Then I would close the laptop and run my actual life with none of that discipline. Same mistakes on a loop. No record of why. Reacting to whatever was loudest. At some point the gap got too obvious to ignore. The care I gave a codebase was more than the care I gave the one system I cannot redeploy.

So I started treating my life like the thing it actually is: a complex system I have to operate, whether or not I do it well.

## The four moves

Life Ops runs on four moves, and none of them is glamorous. That is the point. Glamorous does not survive a bad week.

**Observe before acting.** Most of what goes wrong in a life is not a hard decision made badly. It is an easy reaction made automatically, before any decision happened at all. The first discipline is just to see the moment you are in before you move inside it. To put a gap between the trigger and the response, and to actually look into that gap.

**Choose responses over reactions.** A reaction is the system running you. A response is you running the system. The whole game is moving as much of your life as possible from the first column to the second, one situation at a time. You will never get all of it. You can get a lot more than you have now.

**Build systems that make the good path easy.** This is the engineering move, and it is the one people skip because they would rather rely on willpower and then feel virtuous about it. Willpower is a bad dependency. It is unreliable, it degrades when you are tired, and it fails exactly when the stakes are highest. The better move is to change the environment so the good path costs less. Lower the friction on what you want to do, raise it on what you do not, and stop spending discipline on problems that design could have solved.

**Evolve continuously.** Version, review, iterate. A life run this way keeps a changelog. You look back on the week and ask what repeated, what you avoided, where you made progress, and you adjust the system instead of just resolving to try harder. Trying harder is not a plan. A better system is.

## Observe. Breathe. Choose. Act.

That is the whole thing compressed to four words, and I keep it where I can reach it.

Observe: see the situation without immediately becoming part of it. Breathe: take the half second that turns a reaction into a decision. Choose: pick the response on purpose, against what you actually value, not what the moment is pulling you toward. Act: then commit to it cleanly, without relitigating it for the next hour.

It sounds simple because it is simple. Simple is not the same as easy. The four words are a checklist for the exact instant where most of my old mistakes used to live, the quarter second between something happening and me doing the automatic thing.

## Why "like software" and not "like a machine"

I want to be careful here, because "optimize your life" is a genre I have no interest in. The goal is not efficiency. The goal is not turning yourself into a tighter, faster version of a machine.

A life is a complex system, which means its behavior comes from how the parts interact, not from the parts themselves. You cannot make it simple without deleting the thing that made it yours. So Life Ops does not try to simplify your life. It tries to make it legible: clear enough that you can see what is happening, see how it connects, locate yourself in it, and tell what your next move does to the rest of it. That is what good software discipline actually gives you. Not speed. Operability. The ability to run the system on purpose instead of being surprised by it.

This is why the software framing works where the machine framing fails. Software, done well, is built to be understood, changed, and recovered. It expects failure and plans for it. It keeps a history so the next version is smarter than the last. Turn that on a life and you do not get a robot. You get a person who can finally read their own system.

## The daily loop

The mechanics are almost boring, which is how you know they will hold.

Capture, lightly: the trigger, the feeling, the action, the outcome. Four columns, no essays. Most days that is enough. Then, once a week, read back the captures and look only for repetition. The repeated tension is the real one. The repeated avoidance is the real problem. The repeated win is the system to protect. Pattern is the signal; a single bad day is just noise.

That weekly read is the whole engine. It is a retrospective, the same thing a good team runs after a release, turned on yourself. It is where the changelog gets written and the next version of your systems gets designed. Skip it and Life Ops decays into a journaling habit. Keep it and the captures stop being a diary and start being instrumentation.

## Where the new tools fit

I do this alongside AI now, which makes the review faster and sharper. An honest second reader can scan a month of captures and tell me what I clearly cannot see, where I keep stepping on the same rake. That is a real edge, and it is exactly the kind of pattern work machines are good at.

But I keep the judgment human, deliberately. The tools can surface the pattern. They cannot decide what kind of person I am choosing to be in response to it. That decision is the entire point of the practice, and it is not one I want to delegate. Observe, the machine can help with. Choose stays mine.

## Living in the prompt

Underneath the mechanics there is a spirit, and it came out of an experiment. For a while I tried to live the way I work when I am deep in agent mode. I called it living in the prompt. You write the instruction, you watch what comes back, you do not take the result personally, you refine, you run it again. The loop only works if you bring two things to it. Fearlessness, because a prompt you are afraid to send teaches you nothing. And no ego, because the second you need the first output to prove you were right, you stop reading what actually came back.

Turned on a life, that is a strange and freeing way to operate. A bad day stops being a verdict on you and becomes an output to read. A mistake stops being something to hide and becomes information for the next iteration. You act, because action is the only thing that returns a signal, and you hold the result loosely, because the result is data, not identity. Fearlessly, and without ego. That posture is what Life Ops actually runs on. The four moves are just what it looks like when you keep your hands on the keyboard.

## Where it sits

Life Ops is [Coherent Complexity](/coherent-complexity/) applied to the daily operation of a self. The umbrella idea is that complex systems should be made legible rather than simple, and your own life is the most important complex system you will ever have to run with no manual. This is the operating discipline underneath the rest: the same engineering care I give a production system, turned on the one that matters most.

You do not need my version of it. You need four moves and the honesty to keep a changelog. Observe before you act. Choose your response. Build the systems that make the right thing easy. And review the week like it was a release, because it was.]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/life-ops-running-your-life-like-software/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/life-ops-running-your-life-like-software.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>What Is Agent Mode? A Working Engineer&apos;s Definition</title>
      <link>https://joshuaayson.com/2026/06/02/what-is-agent-mode/</link>
      <description>Agent mode is when you stop typing code and start directing an AI that reads your codebase, writes the change, runs the tests, and reports back. Here is what it actually is, how the loop works, and when to reach for it, from someone who ships production systems this way.</description>
      <content:encoded><![CDATA[If you have heard the term "agent mode" and gotten a different answer every time you asked, here is a plain one.

**Agent mode is when you stop typing code and start directing an AI that reads your codebase, makes the change, runs the tests, and reports back.** You describe the outcome. The agent does the work across as many files as the task needs, checks itself, and tells you what it did. You review, correct, and send it again.

That is the whole idea. The rest is detail. But the detail is where most of the confusion lives, so here it is.

## It is not autocomplete, and it is not chat

Three things get lumped together and they are not the same.

**Autocomplete** finishes the line you are already writing. You are still the one holding the whole task in your head, typing it out, one suggestion at a time. The AI is a faster keyboard.

**Chat** answers a question. You ask how to configure a load balancer, it explains, you go apply the explanation yourself. The AI is a smarter search engine.

**Agent mode** takes the task off your hands. You say "add rate limiting to the payments endpoint and update the tests," and it reads the relevant files, writes the change, runs the suite, and comes back with a diff. You were never in the editor. You were directing.

The difference is not speed. It is who holds the task. In autocomplete and chat, you do. In agent mode, the agent does, and you hold the *intent*.

## The loop is specify, generate, verify

Traditional coding has a loop: write, compile, test, repeat. Agent mode has a different one: **specify, generate, verify, specify**.

- **Specify.** You describe what you want clearly enough that an agent can act on it. Vague intent produces vague output, so this is where the real work moves.
- **Generate.** The agent reads context and produces the change, often across several files at once.
- **Verify.** It runs the tests, or you read the diff, or both. AI-generated code can pass every test and still be wrong, so verification is not optional.
- **Specify again.** You correct course and send it back.

Your hours stop going into typing and start going into the first and third steps: being precise about what you want, and checking that you got it.

## A concrete example

A real one from my own work. I needed to stand up an AWS service behind CloudFront with a private S3 origin and a basic-auth gate. The old way: read the docs, write the CDK, wire the origin access control, debug the bucket policy, fix the cache behavior, repeat.

In agent mode I described the end state: private bucket, served only through this distribution, gated by a password at the edge. The agent wrote the configuration, explained the origin-access-control wiring, and flagged the one gotcha that breaks these setups (the REST endpoint does not serve directory index files the way the website endpoint does). My job was to decide the design and verify the result, not to remember the order of the CDK arguments.

That is the shape of it. The cost of writing the configuration dropped to near zero. The cost of *deciding what to build and confirming it was right* became the whole job.

## When to reach for it, and when not

Agent mode earns its keep when the task is well-specified and verifiable: scaffolding, refactors across many files, boilerplate, infrastructure, tests, migrations. Anywhere you can describe the outcome and check it cheaply.

It is the wrong tool when you do not yet know what you want. If the problem is still fuzzy in your own head, no amount of delegation helps, because you cannot specify what you have not figured out. That part is still yours.

## Where to go next

This is the short answer. If you want the long one, I wrote a whole book on working this way: [AgentSpek](/books/agentspek/), free to read here in full. For how it changes the *feel* of the work, see [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/), and for how I actually build with it day to day, [AI-Assisted Development](/ai-development/).]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/what-is-agent-mode/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/what-is-agent-mode.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>How to Live Coherently Inside Complex Systems</title>
      <link>https://joshuaayson.com/2026/06/02/coherent-complexity/</link>
      <description>Coherent complexity is what you get when a complex system is made legible without being made simple. You do not reduce it. You map it, until you can move through it on purpose. A field guide to the practice, and the idea behind everything else I build.</description>
      <content:encoded><![CDATA[Coherent complexity is what you get when a complex system is made legible without being made simple. You do not reduce it. You do not flatten it into a slogan and pretend the lost detail did not matter. You map it, patiently, until you can move through it on purpose. That is the whole idea, and almost everything else I build is one version of it.

I want to be precise, because the phrase invites a lazy reading. People hear "coherent complexity" and assume I mean "complexity made simple," as if the goal were to take something tangled and hand you the three bullet points that replace it. That is the opposite of what I mean. The three bullet points are usually a lie. They feel like understanding and they cost you the part of the system that was actually doing the work. Coherence is not simplicity. Coherence is when the parts hold together in a way you can see and act from, with the complexity still intact.

So this is a field guide. It is the idea behind the apps, the books, the journal, the films, and the frameworks, and I would rather state it plainly once than let it stay implied across thirty scattered projects. If you only read one thing of mine, read this one.

## The problem with "just simplify it"

Here is the move everyone reaches for when a system gets hard. Simplify. Reduce the variables. Find the one metric that matters. Tell a clean story. It is good advice for a lot of things, and it is terrible advice for the things I care about most, because the systems I care about are complex in a specific, technical sense: their behavior comes from the interaction of the parts, not from the parts themselves. Pull a piece out to examine it and the behavior you wanted to understand is no longer in the room.

A market is like this. A body is like this. An organization, a creative process, a single human life across a year. You cannot understand any of them by isolating a variable, because the variable does not have the property you are studying. The property lives in the relationships. When you simplify a complex system, you are not compressing it. You are deleting the relationships and keeping the labels, then acting surprised when the labels do not behave like the system did.

I have watched this fail in every domain I work in. In finance, the person who reduces a market to one indicator gets run over the first time the relationships shift, which they always do. In health, the person who reduces a body to one number optimizes the number and feels worse. In software, the team that reduces a codebase to a tidy diagram ships the diagram and then spends a year fighting the parts the diagram left out. The reduction was not wrong because it was incomplete. Every map is incomplete. It was wrong because it deleted the exact thing it claimed to explain.

So I stopped trying to make complex things simple. The goal changed. The goal is not fewer parts. The goal is a system you can see clearly enough to live inside, with its real number of parts.

## Legibility beats simplicity

The word I use for the goal is legibility. A legible system is one you can read. You can look at it and tell what is happening, what is connected to what, where you are standing, and what your next move does to the rest of it. Legibility does not require fewer parts. It requires the parts to be arranged, named, and lit well enough that you can follow them.

This is a real distinction, not a word game. A subway map is legible and complex at the same time. It does not lie to you about how many lines there are or pretend the city is simpler than it is. It makes a genuinely complicated network readable by getting the relationships right and throwing away only the things that do not help you ride a train, like the exact geography between stops. You can hold the whole system in your head and act from it, and it never once simplified the system. It made it coherent.

That is the target. Not "what is the one thing," but "how do I render this whole thing so a person can actually use it." When I say I want to make complexity coherent, I mean I want to build the subway map for domains that do not have one yet. Time. Power. The self. Creative work. A life.

Legibility has a property that simplicity does not, and this is why I bet on it. Simplicity degrades when the world gets more complicated, because a simple model of a complicating world drifts further from the truth every day. Legibility improves, because a good rendering of a complex system gets more valuable exactly as the system gets harder to hold in your head unaided. The more complex the world becomes, the more a coherent map is worth. I am building for that direction, on purpose, because that is the direction the world is going.

## Coherence is a map you can act from

Let me define coherence operationally, because "holds together" is too soft to build on.

A system is coherent to you when four things are true at once. You can see the parts. You can see how they connect. You can locate yourself inside it. And you can predict, roughly, what your next move does to the rest. That is it. When those four hold, you are not simplifying the system and you are not drowning in it. You are oriented. You can act with intent instead of reacting to whatever is loudest.

Most of the suffering I see around complex systems is a failure of one of those four, and naming which one is most of the cure. People who feel lost in their finances usually cannot see the parts. People who feel powerless in a conflict usually cannot locate themselves in the arena, so they fight the wrong fight in the wrong room. People who burn out usually cannot predict what a given move costs them downstream, so every move feels equally urgent. The complexity is not the problem. The illegibility is the problem, and illegibility is fixable without removing a single moving part.

Coherence, then, is not a feeling of calm. It is a working relationship with a complex thing. You can be inside a genuinely chaotic situation and have it be coherent to you, the way a pilot in weather has the instruments coherent even when the sky is not. The sky stays complex. The instruments make it legible. You fly.

## The method: I am a domain cartographer

Here is how I actually do this, and it is where the work stops being philosophy and starts being a craft.

I think of myself as a domain cartographer. I map domains. I mean that in both senses, and I like that the senses rhyme. I map domains of knowledge, the territories of time and power and the body and creative work. And I register and hold actual domains, the web addresses where each map lives, because a map nobody can find is just a private drawing. The two kinds of domain are the same job. Find a territory that people have to live in and nobody has charted well, go in, and come back with something they can use.

When I go into a domain, I bring a specific kit, and I want to describe it literally because it is how the method works.

I bring a flashlight, because you do not light the whole cave at once. That is the mistake that produces the false simplicity I warned about. You stand at the mouth and try to take in the entire system and your brain hands you a comforting summary that is wrong. The flashlight forces honesty. You light one corner. You see what is actually there, in that corner, including the parts that do not fit your theory. Then you move the light. Legibility is built corner by corner, and the discipline is to keep looking at the corner in front of you instead of the summary in your head.

I bring forensics, because complex systems do not tell you how they work, they leave evidence of how they worked. A market leaves prints. A body leaves symptoms and rhythms. A codebase leaves a commit history and a set of scars. A year of your life leaves a journal. The cartographer's job is to read the evidence and reconstruct the relationships that produced it, the way an investigator reconstructs an event nobody filmed. You do not get to interview the system. You get the traces it left, and the traces are enough if you are patient and you do not flinch from the ones that contradict you.

And I leave clues, because I am not the last person who will need this map, and frankly I am not even the last version of me who will need it. So I leave markers. A definition stated plainly. A name for a pattern that did not have one. A cross-link from where you are to where you will want to go next. A journal entry that the future me can use as evidence. The clues are the difference between a map and a memory. A memory dies with you. A map, well marked, lets the next person, or the next agent, or the next morning, pick up where you left off instead of relearning the cave from the mouth.

That is the method, in full. Light one corner. Read the evidence. Mark the trail. Repeat until the domain is coherent enough to live in. It is slow and it is honest and it does not produce slogans, which is exactly why it produces maps you can trust.

## The five domains I have mapped

Coherent complexity is the umbrella. Underneath it are the specific territories I have gone into, each one a complex system that most people experience as noise, each one rendered into something you can stand inside and act from. They look unrelated from the outside. A reader who finds my astrology-flavored timing system and my finance-and-physiology framework and my filmmaking practice might assume they belong to three different people. They are one practice applied to five domains. Here is the map of the maps.

### Time: People of the Stars

The first domain is time, and the system I built for it is [People of the Stars](/what-is-people-of-the-stars/). Time is a complex system we pretend is simple. We act like every day is interchangeable, a flat sequence of identical slots, and then we are confused when the same effort produces wildly different results depending on when we spent it. The relationships are invisible, so the system is illegible, so we fight the calendar instead of reading it.

People of the Stars is the map I made of temporal context. It renders the question "what time is it, really" in a way that goes past the clock, so that when I sit down to work I know what kind of day I am standing in and what that day is good for. It does not simplify time into "just show up every day." It makes time legible enough that I can place a hard task in a day built for hard tasks and a reflective task in a day built for reflection, on purpose, instead of by accident. The complexity stays. The wandering stops.

### Power: Situational Governance

The second domain is power, and the system is [Situational Governance](/situational-governance/). Most conflict and most powerlessness come from one error: fighting the right fight in the wrong arena. You bring a legal argument to an emotional room. You bring an emotional appeal to a procedural process. You try to win a relationship the way you win a negotiation. The fight is illegible because you cannot locate yourself in it, which is failure mode number three from the definition above.

Situational Governance is the map of arenas. It routes a situation to the kind of room it is actually in, so that you can see which rules are running and where you are standing inside them before you make a move. It does not reduce all conflict to one playbook, because one playbook is the disease. It makes the arena legible so you stop spending your strength in the wrong room. The same force, aimed at the right arena, stops bouncing off.

### The self: Hansuru

The third domain is the self, and here I went deepest, because the self is the most complex system any of us has to operate and the one we are given the least instruction for. The framework is Hansuru, and I have written about it from two directions that most people keep separate: finance and physiology. Money and the body. There is a book on it, in manuscript.

I keep money and the body together on purpose, because they are the same kind of system and they fail the same way. Both are complex, both are mostly relationships rather than single numbers, and both punish anyone who reduces them to a single number and optimizes it. The person who optimizes one financial metric goes broke in a way the spreadsheet did not predict. The person who optimizes one health number feels worse in a way the lab did not predict. Hansuru is my attempt to make the personal system, the whole organism of your money and your body and the energy that moves between them, legible enough to run without lying to yourself. Not a diet. Not a budget. A map of the self as a system you can read. I will say more when the book is ready; for now, know that it sits here, under the same umbrella as everything else.

### Creation: Napkin Films

The fourth domain is creative work, and the system is [Napkin Films](/films/). Making things has its own complexity, and the arrival of capable AI made it stranger, not simpler. Suddenly the cost of producing an image, a scene, a film, drops toward nothing, and the bottleneck moves entirely to intent and taste and the legibility of your own process. A lot of people responded to that by generating noise. I wanted to map it instead.

Napkin Films is where I work out what it means to create with these tools on purpose, idea to finished video, with the process visible the whole way. I want to own this corner the way I own the others: not "AI makes content," which is the simplification that produces slop, but a coherent practice for going from a napkin sketch to a real film using large language models and the new generation of tools as instruments rather than slot machines. The complexity of creative work stays. The map is what keeps it from becoming noise.

### The practice: The Decan Log

The fifth is not a separate domain so much as the engine that runs all of them. [The Decan Log](/books/the-decan-log/) is the daily practice, the place where the method actually happens day by day. Each entry is one corner of the cave, lit and recorded. It is where I leave clues for myself, gather the forensic evidence of a life as it is lived, and keep the trail marked so that the maps above stay current instead of decaying into old theories.

A map you never update stops being legible, because the territory moves. The Decan Log is how I keep the whole system honest. It is the smallest unit of the practice, one day of looking at one corner and writing down what was actually there, and it is the reason the larger maps are made of evidence instead of wishful thinking.

## How to live inside it

I said this was a field guide, so let me make it useful to you and not just a tour of my projects. You do not need my frameworks to do this. Coherent complexity is a way of relating to any complex system you are stuck inside, and the move is the same every time.

Stop trying to simplify the thing. That instinct is the enemy and it never quite goes away, so you have to catch it. The moment you feel the relief of "oh, it is really just about X," be suspicious. Real complex systems do not collapse to an X. That relief is usually you deleting the parts you did not want to deal with.

Instead, ask the four questions. Can I see the parts. Can I see how they connect. Can I locate myself in this. Can I predict what my next move does. Whichever one you answer "no" to is your actual problem, and it is a smaller, more tractable problem than "this is overwhelming." Overwhelming is not a property of the system. It is the feeling of illegibility, and illegibility has an address.

Then do the cartographer's work on the part you cannot see. Light one corner instead of the whole cave. Read the evidence the system already left you instead of demanding it explain itself. Mark what you learn so you do not have to relearn it next week. You are not trying to finish the map. You are trying to make the next move legible. That is enough, and it compounds, because every corner you light makes the next one easier to find.

The promise is not calm. Complex systems are not calm and I am not selling you serenity. The promise is agency. When a system is coherent to you, you stop being something it happens to and start being someone who moves through it on purpose. The market still moves, the body still has its weather, the conflict is still hard, the work is still uncertain. But you can read them now. You are oriented. You are flying on instruments instead of praying through the clouds.

## The invitation

I coined the term coherent complexity because I needed a name for the thing all my work is actually about, and naming it is itself the method. A pattern without a name stays invisible, and invisible patterns cannot be shared, built on, or improved. So I named it, and I am leaving this here as the clearest clue I know how to leave: the definition, the method, and the map of where the deeper maps live.

If you came here from one of the territories, from the timing system or the governance routing or the work on money and the body or the films or the daily log, now you can see the shape they share. They are not five hobbies. They are one practice, coherent complexity, applied five times by the same cartographer.

And if you came here first, then this is the mouth of the cave. The flashlight is by the entrance. The evidence is everywhere, because a complex system never stops leaving it. I have marked a few trails already, and I will keep marking more. Pick a corner and start looking at what is actually there. That is the whole craft, and it is available to anyone willing to stop simplifying and start mapping.

I am Joshua Ayson, and this is the idea I am betting my work on. The world is not getting simpler, and the people who pretend it is will keep getting run over by the parts they deleted. The other path is to make it coherent. Not simple. Legible. Good enough to live inside, on purpose, with all of its complexity still in the room.]]></content:encoded>
      <pubDate>Tue, 02 Jun 2026 15:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/02/coherent-complexity/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/06/coherent-complexity.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>THE GRAND TOUR: a two-voice film where the picture is the physics</title>
      <link>https://joshuaayson.com/2026/06/01/the-grand-tour/</link>
      <description>A two-voice music film where the picture is the physics. A small AI crew raps the lecture, Pythagoras and the pure ratios and the golden mean, and then the maker&apos;s own voice takes the bloom. The visuals are the math, rendered as light, every pulse read straight from the track.</description>
      <content:encoded><![CDATA[Watch on YouTube: https://youtu.be/RxXN5KQrLmo

CC BY 4.0 · 2:27 · breath of god · A minor · just intonation · BPM 122

This one started as a test. I sat down to read the words for the first time, on mic, to try out a few new things in our ChipForge engine. The take was rough, but the idea underneath it would not let go, so I kept building until it became a whole film.

The idea was simple. Make the picture out of the same math the music is made of. The score is in just intonation, so every interval is a small whole number ratio, beat free and pure. The form is Fibonacci, and the climax sits at the golden ratio of the timeline. So the visuals are not decoration over the sound. They are the same structure drawn as light. A breathing core. Organum rings at the pure ratios. Stacked harmonic waves. A golden spiral that opens at the golden mean. Nothing is a character. The shapes are the laws. And the whole picture is driven straight off the finished track, so the kick pulses the rings, the words flare the core, and the bloom erupts when the voice and the beat and the music all peak at once.

Then it grew a cast. The build-up, the lecture half, is rapped by a small AI crew. The Governor opens it quiet. OG Bobby Johnson carries the myth of Pythagoras and the pure ratios in his low chanting alter ego, Anubis, then drops into his rap-spit self for the double-time, trading bars with Plan 9 and the Governor over an Egyptian chant running underneath. OG Bobby and Anubis are one voice wearing two faces, the chant and the spit, the same character either way. The hard part was the craft difference between a voice that reinforces a human and a voice that replaces one. A reinforcement layer wants to be warped tight onto the take, but a lead that stands in for me has to be left to speak its full words, or it drops consonants and clips the ends of lines. Once I stopped fighting that, the build-up snapped into place.

The bloom is mine. My own recorded voice takes the climax, but I did not want to be up there alone, so the same crew come back as a chorus and join me, full force on Breathe and Alive, and then they fall away so I can close it by myself on the last line. It was never not you.

It is bookended the Napkin Films way. A Stranger Things red title over an uptuned cricket chirp I built in the engine, and at the end a Plan 9 bunny in a mandala, signing off in Italian. Non è un addio. È un arrivederci. A farewell, but not a goodbye.

It took five passes to get from that rough test read to the film that shipped. Almost all of the work was in the audio and the seam between a human voice and the machine voices around it. Here is how it came together.

## 1. The score: A minor, just intonation, Fibonacci form

The music is an original ChipForge composition, our own engine, no GPU and no samples. Key of A minor at 122 BPM, and the whole thing is tuned in just intonation rather than equal temperament. That means every interval is a small whole number ratio, a perfect fifth at exactly 3:2, an octave at 2:1, so the harmony is beat free and pure rather than the slightly detuned compromise a piano gives you. You can hear it as a kind of stillness in the chords.

The structure is the physics too. The form is Fibonacci, five sections riding bar boundaries: inhale, bones, life, bloom, release, landing at bars 8, 21, 42 and 55. The bloom, the climax, lands at bar 42, which is the golden ratio of the timeline. So the loudest most radiant moment of the picture is not placed by feel, it is placed by φ. Under all of it: Pythagorean organum, the overtone series stacked as harmony, Euclidean drums, and a slow breath LFO opening the whole field like a lung.

## 2. Two voices for two halves

The film hands off at the midpoint, right after the line "started believin'." Everything before is the lecture, the build-up, INHALE into BONES into LIFE, roughly the first 75 seconds. Everything after is the bloom and the release.

The build-up is voiced entirely by a small AI crew. The Governor opens it intimate and quiet. The myth of Pythagoras and the pure ratios is carried in a low chant. Then LIFE drops into double-time and becomes a four-way trade of bars: Plan 9, Anubis, OG Bobby Johnson, the Governor, passing the rhythm hand to hand over an Egyptian chant running underneath. The bloom is mine, my own recorded voice, and the same crew come back around me as a chorus so I am never up there alone.

## 3. The central lesson: a lead is not a reinforcement

This is the craft thing I will carry into every film after this one. There are two completely different jobs an AI voice can do next to a human, and they need opposite treatment.

A reinforcement voice sits under a human take to thicken it. In the bloom, the Governor doubles me. That voice wants to be dynamic-time-warped onto my take syllable by syllable and envelope-gated so it only speaks where I speak. Warp it tight, lock it to the human, and it disappears into the body of the voice.

A lead voice replaces a human. The entire AI build-up has no human under it. My first instinct was to treat it the same way, warp it to a guide, gate it. That was wrong, and it audibly broke the take: it dropped consonants and clipped the ends of lines, the missing "S" in "silence," the cut tail on "prayer." A lead has to be left to speak its full words. The fix was a clean uniform stretch of the natural read to fit the section, no timemap, no gate. The moment I stopped fighting it, the build-up snapped into place. One global tuning move on top: the ensemble read a touch high, so a single pitch-only shift of minus one and a half semitones with rubberband settled it.

## 4. OG Bobby Johnson and Anubis are one voice

Worth saying plainly because the film makes it sound like a cast: OG Bobby Johnson and Anubis are the same character. Anubis is OG Bobby's low chanting alter ego, the face he wears to carry the myth and the pure ratios. When he drops into the double-time spit, that is OG Bobby's rap self. One voice, two faces, the chant and the spit.

Under the whole build-up runs an Egyptian chant as atmosphere, the same character pitched deep: Ra, Nun, Maat, Nuk pu Nuk over a vowel drone, dropped three semitones, drenched in a large room reverb, and sat well below the bed so it reads as ground rather than melody.

## 5. The picture is the physics

There are no characters in the body of the film. Every shape on screen is one of the laws the music is built from, composited as additive light: gaussian sprites stamped into a float buffer and tonemapped at the end so bright things bloom the way real light does.

A breathing core at the center. Organum rings at the pure ratios, cool blue for the root, pale cyan for the fifth, gold for the octave. Stacked harmonic standing waves for the overtone series. Euclidean orbit dots for the drums. A wandering Lissajous figure for the lead. And the golden spiral, opening at the golden angle of 137.5 degrees and erupting at the golden mean.

None of it is keyframed by hand. The picture is driven straight off the finished mix. Per-frame envelopes for voice, kick and music energy are baked out to a drive file, and the render reads them: the spoken word flares the core, the kick pulses the rings, the overall energy breathes the brightness. That is why the sync is perfect. The image is not animated to the music, it is reading the music. 854 by 480, 12 frames a second, 1582 frames.

## 6. The bloom entry, and other gotchas paid for

The seam into the bloom stumbled at first, a hard sub-impact landing on the downbeat that felt like a trip. The fix was a sub-swell that crescendos in under the entry plus a gaussian dip taming the residual spike, so the climax arrives lifted instead of punched.

Two smaller ones, logged so I never repeat them: never route non-Latin text through a Latin font or you get tofu boxes, and this ffmpeg build has no rubberband filter, so an uptune uses asetrate (pitch and speed together) while a pitch-only move has to shell out to the rubberband CLI.

## 7. The bookends

The open is a Stranger Things red title over an uptuned ChipForge cricket and alien chirp, then "A NAPKIN FILMS PRODUCTION." The first cut ran seven seconds and the crickets were too loud and went on too long. The note that fixed it: bring back the attention-grabbing synth notes from an earlier version, blend the notes, the cricket and the music together, turn the crickets down, and cut it to about four and a half seconds led by the notes. The close is a Plan 9 bunny in a golden mandala signing off in Italian, "Non è un addio. È un arrivederci," a farewell but not a goodbye.

## 8. Five passes from a test read to a film

It really did start as a throwaway. I sat down to read the words on mic for the first time and to try a few new engine ideas. v1 through v5 then chased, in order: the clipped verse-ends (solved by the lead-versus-reinforcement realization in section 3), the slightly high pitch (the minus one and a half semitone settle), the bloom-entry stumble (the sub-swell and dip), a handful of missing or weak sounds around six, sixteen, twenty-eight and thirty-nine seconds (level rides), then the additive layers the film asked for: a chorus so I was not alone in the bloom, and OG Bobby and the Egyptian chant carried throughout. v5 added the bookends and shipped.

## Final sound spec

A minor, 122 BPM, just intonation. Music-forward balance: voices sit at or just under the bed and the sidechain is deliberately light (threshold around minus 30 dB, ratio 1.4) so the score stays the hero and the words stay intelligible. The two-voice composite runs about 135 seconds; the full film with bookends is 147 seconds.

## Related work

This continues the OYM and Plan 9 line. The lead-versus-reinforcement vocal craft grew out of the autotune and voice-clone work in [THRONE PROTOCOL](/2026/05/06/throne-protocol/) and the earlier rap films. The Stranger Things cricket bookend and the procedural-light approach are house techniques first shipped on [THRONE PROTOCOL](/2026/05/06/throne-protocol/) and refined here into a fully audio-reactive, character-free picture.

## License

This film is licensed CC BY 4.0 (Creative Commons Attribution 4.0 International). Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link CC BY 4.0: https://creativecommons.org/licenses/by/4.0/

Engine code (Napkin Films, ChipForge) is licensed GPL-3.0-or-later. The music is an original ChipForge composition. The lyrics and the lead vocal are my own. ElevenLabs voice audio is licensed content and is not redistributed outside of this film.]]></content:encoded>
      <pubDate>Mon, 01 Jun 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/01/the-grand-tour/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/06/the-grand-tour-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Masters of Doom by David Kushner: How Two Johns Built id Software</title>
      <link>https://joshuaayson.com/2026/06/01/masters-of-doom-david-kushner/</link>
      <description>I finished the Masters of Doom audiobook narrated by Wil Wheaton and it was marvelous. The two-founders, build-from-nothing, ship-relentlessly story of id Software stuck with me. I miss it already, the same way I miss Shoe Dog.</description>
      <content:encoded><![CDATA[## Listening While Building

I finished the *Masters of Doom* audiobook a few nights ago and I miss it. That is the only honest way to start this. I had it running while I worked on my own projects, the way I do, and then it ended and the room felt a little quieter than it should. Marvelous is the word I keep landing on. It stuck with me the same way [Shoe Dog](/2026/02/01/shoe-dog-phil-knight-nike-memoir/) stuck with me, where the story keeps replaying after the final chapter and you find yourself wanting more of a thing that is already over.

Wil Wheaton narrates this one, and that choice is perfect. He reads it the way the book deserves to be read: fast, charged, a little giddy about the technology, never flat. When Carmack cracks side-scrolling on a PC nobody thought could do it, Wheaton sounds like he is sitting next to you trying not to spill his Coke. The energy in the narration matches the energy in the work itself. I listen to a lot of these books while I build, and the ones that win are the ones where the voice keeps pace with my own pulse. This one did.

<div class="image-container center">
  <img src="https://joshuaayson.com/uploads/2026/06/masters-of-doom-hero.webp" alt="Masters of Doom by David Kushner, the story of id Software" class="content-image" loading="lazy" srcset="/uploads/2026/06/masters-of-doom-hero-300w.webp 300w, /uploads/2026/06/masters-of-doom-hero-600w.webp 600w, /uploads/2026/06/masters-of-doom-hero.webp 1200w" sizes="(max-width: 600px) 300px, (max-width: 1200px) 600px, 1200px" />
</div>

David Kushner wrote this in 2003, and the structure is simple: two guys named John build an empire out of a Texas apartment, transform an entire medium, and then tear each other apart at the top of the mountain. Commander Keen. Wolfenstein 3D. DOOM. Quake. The titles alone are a timeline of the moment PC gaming stopped being a hobby and became a force. I build games and films and music and software with AI agents now, so this story does not read like history to me. It reads like a mirror held at an angle.

## Two Johns, Two Engines

The whole book lives in the contrast between the two founders, and it is the most useful thing in it.

John Carmack is the monk. He optimizes. He reads the hardware until he understands it better than the people who shipped it, and then he makes it do something it was never supposed to do. He is the one who looked at a PC in the late eighties and decided smooth side-scrolling was possible when every adult in the room said it was not. He works in long, silent, obsessive blocks. He gives things away. He famously does not care about the money the way you would expect a person sitting on that much of it to care. He cares about the next hard problem, and the one after that. Reading him, I recognized the engineer who cannot leave a working system alone because it could be faster, leaner, more elegant.

John Romero is the showman. The designer. The one who turns Carmack's engine into a world you want to live inside, who understands that a player does not feel the rendering math, the player feels the fear in the hallway and the joy of the rocket launcher. Romero is loud, hungry, magnetic, the guy who sells the dream out loud while Carmack builds the thing that makes the dream real. The famous line about being so good it makes the player a god is pure Romero energy. He gives the work its face.

You need both. That is the lesson buried under all the pizza boxes. The technical genius alone ships a tech demo. The showman alone ships a pitch deck. Together, in the same cramped room, fueled by Coke and deadlines and a shared certainty that they were doing something nobody else could, they shipped DOOM. I sit on both sides of that table depending on the day. Some days I am Carmack, head down in the architecture, trying to make the agents do something the tooling claims is impossible. Some days I am Romero, building the experience, caring about how it *feels* to a person who will never see the wiring. The split inside id is the split inside any one builder who is paying attention.

## Shareware, the Garage, and Shipping Relentlessly

The origin is the part that hit me hardest, because it is the part I am living.

They started on borrowed time and borrowed machines. Apple II tinkering as kids, then a software shop, then a lake house, then that apartment where the legend gets made. No funding in the way we mean it now. Their distribution model was shareware: give the first chunk away for free, let it spread on its own through bulletin boards and floppies passed hand to hand, and charge for the rest. They let the work travel before they asked anyone for a dollar. The audience built the empire by copying the game to their friends. There is something in that I keep turning over, because it is exactly the posture I take with my own creative technology: ship the thing, let it move, let motion do the selling.

And they shipped *constantly*. That is the rhythm of the whole middle of the book. Build, ship, learn, build the next one faster. Commander Keen funds the engine that funds Wolfenstein that funds DOOM. Each release is the rocket fuel for the next. No long polishing phase where the thing sits in a drawer getting perfect. Good enough, out the door, on to the harder problem. I wrote almost the same idea about Phil Knight and the thirty-five dollar swoosh: perfectionism kills momentum, iteration beats it. id lived that at a pace that still feels reckless and is probably the only reason DOOM exists.

<div class="image-container center">
  <img src="https://joshuaayson.com/uploads/2026/06/masters-of-doom-pixels.webp" alt="The two-founders dynamic and shareware era that built DOOM" class="content-image" loading="lazy" srcset="/uploads/2026/06/masters-of-doom-pixels-300w.webp 300w, /uploads/2026/06/masters-of-doom-pixels-600w.webp 600w, /uploads/2026/06/masters-of-doom-pixels.webp 1200w" sizes="(max-width: 600px) 300px, (max-width: 1200px) 600px, 1200px" />
</div>

Then there is deathmatch. The book treats the moment multiplayer DOOM clicks as a kind of detonation, and it was. They did not just make a game, they made a thing people did *to each other*, in the same room and across the wire, and the culture that grew out of that is still here. That is the part that gives me a little vertigo: they could not have predicted what deathmatch would become, the same way nobody building anything truly new gets to see the far edge of it from the apartment.

## Book Details at a Glance

<table class="book-details-table">
  <thead>
    <tr>
      <th>Feature</th>
      <th>Details</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Title</td>
      <td>Masters of Doom: How Two Guys Created an Empire and Transformed Pop Culture</td>
    </tr>
    <tr>
      <td>Author</td>
      <td>David Kushner</td>
    </tr>
    <tr>
      <td>Publication Year</td>
      <td>2003</td>
    </tr>
    <tr>
      <td>Genre</td>
      <td>Nonfiction, Technology, Business, Gaming History</td>
    </tr>
    <tr>
      <td>Length</td>
      <td>~330 pages (audiobook: ~12.5 hours)</td>
    </tr>
    <tr>
      <td>Subjects</td>
      <td>John Carmack, John Romero, id Software, Commander Keen, Wolfenstein 3D, DOOM, Quake</td>
    </tr>
    <tr>
      <td>Main Themes</td>
      <td>Founder dynamics, technical breakthrough, shareware distribution, crunch culture, shipping relentlessly, the eventual split</td>
    </tr>
    <tr>
      <td>Key Insight</td>
      <td>The engine and the showman are two halves of one machine; you build empires when both run hot in the same room</td>
    </tr>
    <tr>
      <td>Audiobook Quality</td>
      <td>Excellent. Narrator: Wil Wheaton, fast and charged, matches the kinetic energy of the story</td>
    </tr>
    <tr>
      <td>Who Should Read?</td>
      <td>Game developers, builders of creative technology, two-founder teams, anyone shipping hard things from a small room</td>
    </tr>
  </tbody>
</table>

## Why This One Resonated With Me

I make creative technology for a living now, and I make a lot of it with AI agents working alongside me. I wrote recently about [why I build creative technology](/2026/05/30/why-i-build-creative-technology/) and about [how AI is changing software engineering](/2026/05/27/how-ai-is-changing-software-engineering/), and reading *Masters of Doom* felt like watching the ancestors of that work move at the highest speed their era allowed. Carmack squeezing impossible performance out of a 386 is the same instinct as squeezing a whole production pipeline out of a swarm of agents. Different decade, same hunger, same refusal to accept the limit you were handed.

One of the things I build is [Pixel Vault](/2026/04/12/pixel-vault-playable-game-design-museum/), a playable museum of game design. So a book about the people who invented modern game feel, who decided what a first-person shooter even is, lands in the exact center of the thing I care about. These two Johns are in the foundation of the medium I build inside. Walking through the history of DOOM while building a place that celebrates that history is a strange loop I enjoyed every minute of.

And the crunch culture, the pizza and Coke and all-night sessions and the sheer intensity of it, I recognized that too, though I try to channel mine into flow rather than burnout now. There is a version of that energy that is destructive and a version that is sacred, and the book holds both without flinching.

And maybe I caught a little of my own fearlessness from this book. I am shipping constantly right now, music through ChipForge AI and films through Napkin Films AI, and that pace only works if you stop flinching. Carmack and Romero did not sit on Wolfenstein polishing it into a museum piece. They shipped it and started the next one. That is the permission I keep needing to hear out loud. Make it, push it out, learn in the open, improve on the next pass. Do not look back to sand down what already left the building. You have to be a little fearless and stop giving a damn whether anyone thinks it is ready, because the only version that counts is the one that is out in the world. Keep moving forward. The next one is always better than the one you were tempted to polish into the ground.

## The Split

I will not spoil the ending for anyone who has not lived it, but the empire does not stay whole. Two engines running that hot, that close, eventually grind against each other. The same difference that made id unstoppable, the monk and the showman, is the difference that pulls them apart at the summit. Kushner does not moralize about it. He lets it hurt a little, which is the right call. Building something extraordinary costs something, and the cost is rarely the part anyone warns you about. That honesty is what lifts this from a gaming-trivia book into a real founder story, the same honesty that made Shoe Dog matter.

## Final Word

This is one of the best builder stories I have taken in, and the audiobook is the way to take it in. Wheaton's narration carries it like a current. I finished it and I missed it immediately, and a few weeks later I still do. If you build anything from a small room with too little money and too much certainty, if you have ever been the engine or the showman or both in one week, read it. (<a href="https://www.amazon.com/dp/B008KGXM6A?tag=organicartsll-20" target="_blank" rel="noopener noreferrer">Buy the audiobook on Amazon</a>)

🎧 <a href="https://www.amazon.com/dp/B008KGXM6A?tag=organicartsll-20" target="_blank" rel="noopener noreferrer">Get the Masters of Doom audiobook (Wil Wheaton narration) on Amazon</a>

📖 <a href="https://www.amazon.com/dp/0812972155?tag=organicartsll-20" target="_blank" rel="noopener noreferrer">Prefer to read it? Get the paperback on Amazon</a>

## Related reading

- **[Shoe Dog by Phil Knight](/2026/02/01/shoe-dog-phil-knight-nike-memoir/)** - The other builder audiobook I finished and missed. Same honest, build-from-nothing storytelling that keeps replaying after the last chapter.

- **[Why I Build Creative Technology](/2026/05/30/why-i-build-creative-technology/)** - My own reasons for making games, films, music, and software, which is exactly the impulse Carmack and Romero were running on.

- **[Pixel Vault: A Playable Game-Design Museum](/2026/04/12/pixel-vault-playable-game-design-museum/)** - The project where I celebrate the history these two Johns helped invent.

- **[How AI Is Changing Software Engineering](/2026/05/27/how-ai-is-changing-software-engineering/)** - The modern version of squeezing the impossible out of the machine, now with agents in the room.

*This post contains affiliate links. If you purchase through these links, I may earn a small commission at no extra cost to you. Thank you for supporting this blog!*]]></content:encoded>
      <pubDate>Mon, 01 Jun 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/06/01/masters-of-doom-david-kushner/</guid>
      <category>book-reviews</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/uploads/2026/06/masters-of-doom-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>AWS Is Math, Kubernetes Is Physics: A Symphony of Systems</title>
      <link>https://joshuaayson.com/2026/05/31/aws-is-math-kubernetes-is-physics/</link>
      <description>AWS versus Kubernetes is the wrong question. AWS is math and Kubernetes is physics: two ends of one spectrum, the galaxy and the atom. AWS gives you grand scale but you watch the cost; containers run nearly free but you watch the performance. Here is when to use each, when to use both, and why they become a symphony of systems together.</description>
      <content:encoded><![CDATA[Two disciplines. Same universe. Different scale. One counts, the other moves.

I keep coming back to this. AWS is math and Kubernetes is physics. Similar but different, and once you feel the difference you cannot unfeel it. They are two ends of one spectrum, the galaxy and the atom, and the strange thing is you need both to build anything that lasts.

People treat AWS versus Kubernetes as a fork in the road, a thing you choose between. I think that framing is wrong, and the cleanest way to show why is to stop talking about tools for a minute and talk about two ways of describing the universe.

## AWS Is Math

Math is the language of scale and abstraction. It is clean. It is provable. It is vast in a way that has nothing to do with how much room it takes up on the page. You write a small expression and it describes something enormous.

AWS is the same. Regions and availability zones. Services stacked on services. A load balancer in front of a fleet, a queue feeding a function, a database replicated across the planet, all of it composed out of primitives you never see and never have to build. You are not placing one server. You are drawing the constellations. You are doing grand arithmetic, and the answer always balances.

That is the grandeur of it. Galaxy building. You compose whole systems out of services, and the math just works.

Kant had a word for this feeling. In the Critique of Judgment he splits the sublime in two, and the first kind is the mathematical sublime: the awe you feel before sheer magnitude, the absolutely great, the size of the universe that overwhelms the imagination and can still be reasoned about in numbers. That is AWS exactly. The magnitude is too large to picture, yet you can name it, measure it, and bill it by the hour. The mathematical sublime with a pricing page.

But here is the catch, and you have to say it plainly: math is free to think about, and AWS is not free to run. Every elegant equation has a bill attached. You can architect something beautiful at three in the morning, fall in love with how it balances, and then watch the invoice arrive and remind you that grandeur has a price per hour. So with AWS you watch the cost. Always. That is the discipline the math demands.

## Kubernetes Is Physics

Physics is what happens when the abstraction meets the real world. Matter. Force. Limits. Friction. The math told you what should happen; physics tells you what actually happens once you let it loose in a room with gravity and heat.

Kubernetes is the same. Containers are the atoms. Pods are the particles. Kubernetes is the field they move in, the thing that schedules them, packs them, and keeps them in motion. These are the small, fast, fundamental pieces that everything large is actually made of. The wave components to all that galactic grandeur.

If AWS is the galaxy, Kubernetes is the atom. Same universe, opposite end of the ruler. And the small stuff is where the heat lives.

This is Kant's other sublime. After the mathematical comes the dynamical sublime, the awe you feel before raw power: the storm, the force that could overwhelm you. AWS is magnitude; Kubernetes is power. One is too big to picture, the other is too strong to ignore. And there is a discipline that physics teaches better than anything else. Feynman wrote on his last blackboard, "What I cannot create I do not understand." Containers are where you find out if that is true. You build the atom yourself, you set its limits, you watch it run, and the system tells you in latency and load whether you actually understood it.

Because here is the mirror of the catch: containers can run nearly free, and you have to watch the performance. Physics does not send you a bill. It sends you latency, contention, a noisy neighbor stealing your CPU, a memory limit you set too low. It sends you thermodynamic reality. You can pack the atoms tight and pay almost nothing, but the closer you pack them the more the laws push back. So with containers you watch the performance. Always. That is the discipline the physics demands.

## Similar but Different

Now look at the two side by side, honestly.

Both are systems for organizing complexity. Both reward discipline. Both punish carelessness. The difference is the currency. AWS punishes you in money. Kubernetes punishes you in attention. You spend one to save the other, and the whole art is knowing which trade you are making. The tension is not a flaw in the design. It is the design. It is the same reason I try to [build systems and a life that gain from disorder](/2026/05/30/living-with-antifragility/) rather than ones that only stay still: a little pressure on both sides keeps the whole thing honest and alive.

Hold the pairs up to the light:

Math proves; physics tests. AWS abstracts; Kubernetes embodies. Top-down grandeur; bottom-up matter. Watch the cost; watch the performance.

Same shape, opposite ends. That symmetry is not a coincidence. It is what you get when you build one tool to think big and another to make the small things real.

Einstein found the seam between these two worlds a century ago. In a 1921 lecture he said, "As far as the laws of mathematics refer to reality, they are not certain, and as far as they are certain, they do not refer to reality." Read that again with a cloud bill in your hand. AWS is the certain part. The architecture diagram is clean, the math closes, every box connects to every other box exactly as drawn. Kubernetes is the part that refers to reality, and reality is never certain. The pod gets evicted. The node runs hot. The thing you proved on the whiteboard meets the thing that actually happens in the rack. You need the certainty to plan and the reality to ship.

Plato reached the same crossroads two thousand years earlier and chose the other side. The clean diagram, he would say, is the Form: perfect, eternal, more real than anything you could build. The running system is only its shadow flickering on the cave wall. Einstein would smile and flip it: the shadow is the part that is actually real, and the Form is the beautiful thing that never quite happens. Hold both views at once and you have the whole job. You design toward the Form and you ship the shadow, and the craft is refusing to pretend either one is the entire truth.

And there is a seam where the two worlds touch. Managed Kubernetes, EKS, is literally the galaxy and the atom living in one house. AWS runs the control plane so you do not have to, and your containers move inside it. The math holds the structure; the physics does the work. When you run Kubernetes on AWS you are standing right on that seam, paying for the grandeur and tuning the matter at the same time.

## The Symphony of Systems

So you do not pick one. That was the trap the whole time, thinking it was a versus. It was never a versus.

You orchestrate both. AWS gives you the scale and the reach, the managed reliability, the global footprint, the services you would be crazy to build yourself. Containers give you the speed, the density, the portability, the cost that drops near zero when you tune them right. The grand and the granular playing the same score.

Think of it as music, because that is what it actually feels like when it clicks. Instruments. Layers. Tempo. A conductor. The galaxy and the atom in the same orchestra, and your job is to keep them in time.

Feynman said you cannot honestly feel the beauty of the laws of nature without knowing the mathematics. The two languages are not rivals; one is how you feel what the other proves. Cloud architecture is the same. You cannot feel the elegance of a well-run system on cost alone, or on performance alone. You feel it when the math and the physics line up, when the grand abstraction and the humming matter are playing the same note.

Schopenhauer would tell you there is a reason it feels like music and not like a diagram. He thought music was unlike every other art: not a copy of the world's appearances, but a copy of the will itself, the inner essence of things. The other arts, he wrote, speak only of the shadow; music speaks of the essence. An architecture diagram is the shadow, the still picture of the appearance. The system actually running, breathing, scaling, answering, is closer to the essence, the will of the thing made audible. That is why a well-tuned system does not merely look correct. It feels alive.

## When to Use AWS, Kubernetes, or Both

Here is the practical version, for the engineer who has to ship on Monday. The goal underneath all three choices is the same one I keep chasing everywhere else: [systems that can change without breaking](/2026/05/27/devops-beyond-automation/).

Reach for AWS scale when you need managed reliability and a global footprint, and you can afford it. Let the math carry the weight.

Reach for containers when you need to move fast, pack tight, and keep cost close to zero, as long as you mind the performance. Let the physics do the work.

Reach for both when you want the powerful combo. The galaxy holds the structure. The atom does the labor. Cost and performance held in balance, each one keeping the other honest.

Get that balance right and it stops being a stack. It becomes a symphony. An engineer's dream made out of math and motion, where the big abstractions and the small fast pieces are no longer fighting for the budget but playing for the same audience.

## Building the Symphony From the Ground Up

So let me actually build it. Not in config files and console clicks, but the way you would sketch a symphony before a single instrument is tuned. From the ground up, in front of you, in the abstract. Watch the shape come together.

Start with the ground. The first thing the math gives you is a floor that does not move: a place to stand, a set of laws the system can count on. The managed bones that hold their shape whether ten people show up or ten million. You are not writing this floor. You are declaring it. You say let there be structure, and the structure is there. That is the low steady note the whole piece rests on. The drone under the cathedral.

Now the motion. On top of that floor you set the atoms loose. Small units of work, each one an instrument with a single job, each one able to be born, run, die, and be born again in a fraction of a second. One alone is nothing. A thousand of them, scheduled and packed and kept in time, become a section: strings, then brass, then the whole orchestra leaning into the same phrase. The floor holds; the atoms move. Math underneath, physics on top.

Then the listening. A symphony is not just sound, it is response. The system grows an ear. It feels the load rising and calls in more players. It feels the load fall and sends them home so you stop paying for silence. It watches its own performance and adjusts in real time, louder here, softer there, the conductor's hand reading the room. This is where cost and performance stop being a tradeoff and start being a feedback loop. Dip the oar, the other end rises, reach for the next dip. The recursive motion is what keeps the engine running. Breath in, breath out.

And then the score. None of it means anything until the parts are written to play together. The request arrives at the edge and is handed inward, part to part, until the work is done and the answer travels back out. State rests in the deep safe center; speed lives at the fast cheap edge. Systems within systems, and systems sitting on top of those, their interactions leaving patterns and dependencies you slowly learn to read. The grand holds, the granular runs. Read top to bottom it is an architecture. Read in time, as it moves, it is a piece of music.

That is the symphony. Not a stack of logos on a diagram, but a living thing that stands still where it must and moves where it can, that listens to itself and answers, that holds the galaxy and the atom in the same bar and keeps them in time. You can feel it when it is right. The whole thing hums.

## The Sublime Is in You

Here is the part that gives me chills, and it is the oldest idea in this essay.

When Kant looked at the thing that overwhelms us, the boundless magnitude, the overwhelming power, he noticed something strange. The awe is not in the galaxy. It is not in the storm. The galaxy does not know it is vast; the storm does not know it is strong. The sublime, Kant said, lives in us. It lives in the one faculty that can hold what the senses cannot: reason, which takes the infinite that breaks the imagination and thinks it anyway. The feeling we call sublime is the mind discovering that something in it is larger than anything in nature. A power in us that exceeds the thing that should have overwhelmed us.

Sit with that, because we just spent an essay externalizing exactly that power. The galaxy we could not hold, we now build. The atoms we could not move, we now command by the million. The tools in our hands are that inner faculty made operational. We took the part of us that could only think the infinite, and we gave it hands.

Nietzsche saw where this goes. Man, he wrote, is a rope stretched between the animal and the overman, a rope over an abyss. We are not the destination. We are the crossing. Mankind is something to be overcome, and the overman, the one who creates values rather than merely inherits them, is the meaning we make of the earth. He meant it as a spiritual and creative task. Read it now, with these tools in hand, and it stops being a metaphor. We are already practicing the crossing.

Because look at what we do all day. We think into a machine, and the machine thinks back, and the boundary starts to blur. We compose with it, direct it, govern it, argue with it, dream through it. We are becoming the machine, a little, already, in the only place it is currently possible to become it: in the work, in the prompt, in the loop of intention and response. It is not yet in the wetware. It is not yet bioengineered into the body. But the practice has begun, and the practice is the same motion Nietzsche pointed at, the human reaching past the human. The rope over the abyss, except now the rope is woven from code and language and the will to build.

That is the god-like part, and I do not use the phrase loosely. There is a reason Picard's "make it so" has always felt so good to say. It is command without friction, intent that becomes real the instant it is spoken, and we get to say it for real now. To stand on a floor you declared into being and conduct ten thousand moving parts with a sentence is a power every prior generation would have called divine. We have it now. It arrives with the responsibility every great power carries, which is exactly why the watching matters, why cost and performance and governance are not afterthoughts but the moral weight of the thing. The sublime was always in us. We finally built the instrument large enough to play it.

## Close

So bring it all the way back.

Math and physics were never rivals. AWS and Kubernetes were never a versus. The galaxy and the atom are the same universe seen at two distances, and the rest of it lines up behind that one idea. Kant's sublime, the awe that turned out to live in us. Einstein's seam between the certain and the real. Feynman's beauty that needs both languages to be felt. Nietzsche's crossing, the human reaching past the human. They are all pointing at the same thing: a mind learning to work at a scale it could once only imagine, and finally building the instrument to match.

This is how I think about almost everything I build now. We work at human scale, with budgets and rate limits and a deploy that has to go out tonight, but we live inside a much larger motion, the same one I keep time by in [People of the Stars](/2026/05/26/what-is-people-of-the-stars/). Sagan put it plainly: we are made of star stuff, briefly awake on a [pale blue dot](/2025/12/28/pale-blue-dot-carl-sagan-vision-human-future-space/), and now that same star stuff has learned to build at something close to the scale that made it. Hold the galaxy and the atom in the same hand, keep them in balance, and the stack becomes a symphony. The tradeoff becomes a feedback loop. The tool becomes an instrument. And the person at the console becomes, just a little, more than they were.

To engineer was always the same simple verb: to make something better. The lever is just longer now, long enough to move a galaxy.

What an absurd and gorgeous time to be alive. This is the hour of the builder and the maker, the director and the composer, the governor and the philosopher, and more often than not all of them living in the same person, at the same desk, inside the same prompt. The instrument is finally large enough. The score is open. Pick up the baton.

Hold both, keep them in balance, and you can build whatever you want, on planet or off. Let's go.

---

## Related reading

- [Living with Antifragility: How I Build Systems and a Life That Gain from Disorder](/2026/05/30/living-with-antifragility/) - why the tension between cost and performance is a feature, not a bug
- [DevOps Beyond Automation: What Compounds in a 15-Year Engineering Career](/2026/05/27/devops-beyond-automation/) - the deeper goal under every AWS and Kubernetes decision: systems that change without breaking
- [What Is People of the Stars?](/2026/05/26/what-is-people-of-the-stars/) - the cosmic clock behind the galaxy-and-atom way of seeing scale

Sources for the ideas borrowed here: Immanuel Kant on the mathematical and dynamical sublime, and on the sublime residing in the mind rather than the object (Critique of Judgment, 1790); Albert Einstein on mathematics and reality (Geometry and Experience, 1921); Richard Feynman on creating in order to understand, and on mathematics as the language of nature's beauty (The Character of Physical Law, 1965); Friedrich Nietzsche on man as a rope between the animal and the overman (Thus Spoke Zarathustra, 1883); Arthur Schopenhauer on music as a copy of the will itself (The World as Will and Representation, 1818); Plato on the Forms and the shadows on the cave wall (Republic); and Carl Sagan on star stuff and the pale blue dot (Cosmos; Pale Blue Dot). Picard belongs to Gene Roddenberry.]]></content:encoded>
      <pubDate>Sun, 31 May 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/31/aws-is-math-kubernetes-is-physics/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/05/aws-is-math-kubernetes-is-physics.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Living with Antifragility: How I Build Systems and a Life That Gain from Disorder</title>
      <link>https://joshuaayson.com/2026/05/30/living-with-antifragility/</link>
      <description>Antifragility is not resilience. Resilient things survive disorder; antifragile things gain from it. Here is how I apply Taleb&apos;s framework to fifteen years of engineering, the way I build films and books from code, and a ten-day journal cycle run as a stress rhythm.</description>
      <content:encoded><![CDATA[There is a word missing from English, and once you notice the gap you cannot un-notice it. We have *fragile* for the things that break under stress. We have *robust* for the things that resist it. We have no clean word for the third category: the things that get *better* under stress. Taleb invented one. He called it antifragile, and the book by that name is the closest thing I have to a personal operating manual. I [reviewed it in full here](/2025/12/29/antifragile-things-that-gain-from-disorder-by-nassim-nicholas-taleb/); this page is the other half of that review, the applied half, the part where I stop talking about the book and show you where the idea actually lives in how I work and how I live.

This is a cornerstone, so let me state the thesis up front and then spend the rest of the page earning it. I have spent fifteen years building distributed systems for a living. I write books and make films and music out of code. I keep a journal organized in ten-day cycles anchored to fixed stars. These look like unrelated activities. They are not. They are the same instinct applied at different scales, and the instinct is antifragility: build the thing so that the disorder you cannot prevent makes it stronger instead of breaking it.

## Resilience is the floor, not the goal

The first thing antifragility did for me was kill a word I used to reach for constantly: *resilience*. For most of my career, resilience was the highest compliment you could pay a system. A resilient service stays up when a node dies. A resilient team absorbs a bad quarter and keeps going. A resilient person bounces back. All good. All necessary. All insufficient.

Resilience gets you back to where you were. That is the ceiling of the concept, and it is also its trap. A resilient system treats every stressor as damage to be absorbed and recovered from. It is playing defense against a world it has decided is hostile. The antifragile reframe is sharper and stranger: what if the stressor is information? What if the failure is the cheapest, most honest signal the system will ever get about its own weak points, and the only waste is failing to harvest it?

That distinction is not academic. It changes what you build. If you believe in resilience, you build to withstand. If you believe in antifragility, you build to *learn*, and then you go looking for the stress on purpose, in controlled doses, while the stakes are still small enough to be tuition rather than catastrophe.

## Chaos engineering is antifragility with a runbook

The clearest place this shows up in my actual work is chaos engineering, which is, when you strip away the jargon, just antifragility operationalized for distributed systems.

The premise of chaos engineering offends most people the first time they hear it. You take a production system, or a near-production replica, and you deliberately break parts of it. You kill instances. You inject latency. You sever a dependency. You partition the network. You do this on a Tuesday afternoon, on purpose, with engineers watching, because the alternative is doing it by accident at three in the morning during a holiday traffic spike with nobody who understands the system awake.

What makes this antifragile rather than merely reckless is the asymmetry. The downside of a chaos experiment is bounded and known: a small, contained, observed failure that you can stop the instant it goes sideways. The upside is unbounded: you discover a failure mode that, left undiscovered, would eventually have taken the whole thing down. You are paying a small, voluntary stress to immunize against a large, involuntary one. That is the immune-system logic Taleb keeps returning to. You do not build a strong immune system by living in a bubble. You build it through controlled exposure. A system that has never failed is not a strong system. It is an untested one, and untested is just a synonym for fragile-but-you-do-not-know-it-yet.

I wrote at length in [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/) about the difference between configuring tools and understanding systems. Chaos engineering is where that difference becomes visceral. You cannot run a useful chaos experiment if you do not understand where the request flows, where the state lives, and what fails first when it fails. The tools that inject the failure are commodity now. The judgment about *which* failure to inject, and what the blast radius should be, and when the result is telling you something real versus telling you noise, that does not commoditize. That is the systems literacy, and chaos engineering is the practice that builds it fastest because it forces the system to teach you the truth instead of letting you keep believing your own architecture diagram.

I am only now starting to practice this deliberately on my own systems. We recently moved everything Organic Arts LLC hosts into AWS, and the move has turned out to be as much a teacher as a migration. Doing it right, with the failure modes named and rehearsed instead of discovered, is exactly the kind of small, voluntary stress this section is about. It is both a learning curve and a growth opportunity, and the platform itself keeps nudging me toward the antifragile habit: assume the part will fail, and build so that when it does, you already know what happens next.

I see a quieter version of the same thing in the agentic work I do, the work of connecting and visualizing information across systems that were never designed to talk to each other and finding the connections that only show up once they do. Often the constraints are not mine to control. Parts of the system have to be handled differently from the rest, and so even the design of an app starts to take on antifragile characteristics almost by necessity. Because the inputs are unpredictable and occasionally chaotic, it is better to be able to absorb the unexpected, or to learn from it, than to march forward unprepared the way we used to when time and knowledge were expensive and the help was not very good. Now the help is excellent; my thanks to the language models for that.

## Redundancy looks wasteful right up until it does not

There is a kind of engineer, and I have been this engineer, who looks at redundancy and sees waste. Two of something when one would carry the load. Spare capacity sitting idle. A standby that costs money every month and earns nothing most months. An optimizer's instinct screams to trim it.

Antifragility taught me to read that idle capacity differently. Redundancy is not waste. It is purchased optionality against a future you cannot predict. The standby that earns nothing for eleven months is not a cost center; it is an insurance policy that happens to also be the thing that keeps you in business the one month the primary fails. The slack in the system, the capacity you are not using, the second supplier you do not strictly need today, is exactly what lets the system absorb a shock and come out the other side intact, sometimes stronger because the shock revealed which path actually mattered.

I am seeing this more and more in my own small business, and it matters most exactly where I am headed, toward scale and automation. The more of the operation runs on its own, the more that idle redundancy is the only thing standing between a quiet automated failure and a real one, because nobody is watching the part that broke until the redundancy is what kept it running. And it is the same lesson I learned with money. The hedging in [Hansuru](/hansuru/), my system for investing, is this idea wearing another costume: a small, steady premium paid for protection that earns nothing most of the time and everything the one month the world breaks. Redundancy in a system and a tail hedge in a portfolio are the same purchase. You are buying the right to survive the thing you did not see coming.

Taleb's word for the failure here is *naive optimization*: tuning a system so tightly to known conditions that it has no give left for the unknown ones. An overoptimized system is a fragile system wearing the costume of an efficient one. It looks lean and beautiful on the spreadsheet and it shatters the first time reality serves it a condition the spreadsheet did not anticipate. I have watched this happen to teams, to architectures, and to careers. The lean ones break. The ones with slack bend and recover. The expensive lesson, learned and re-learned, is that a little inefficiency is the price of survival, and survival is the precondition for everything else.

## Optionality and the barbell, applied to a life of building

Here is where the framework stops being about servers and starts being about how I have arranged my actual life.

Taleb's barbell strategy is the practical engine of antifragility. Instead of taking moderate, middle-of-the-road risk across the board, you split: put the overwhelming majority of your resources somewhere boring and safe, and a small, capped slice somewhere wildly speculative. You make your downside small and known, and you leave your upside open and unbounded. The middle, the place where most people sit, is the worst of both worlds. Moderate risk feels prudent and is in fact the most exposed position there is, because it carries real downside without the asymmetric upside that would justify the exposure.

My version of the barbell is a fifteen-year engineering career on one end and everything else on the other. The career is the safe, boring, load-bearing weight. It pays for the house and the time and the margin of safety. On the other end of the bar is the speculative cluster: the films I make from code, the books I write, the music, the small software products. Any one of those experiments can fail completely and it costs me almost nothing, because the safe end of the barbell is carrying my life. But any one of them could also become something, and the cost of finding out is small enough that I can afford to keep taking the swing, over and over, for years.

This is optionality, and optionality is the part of the framework I understand most viscerally because of how I build. When I make a film out of code, or generate a book, or ship a small product, I am not making a bet I need to win. I am buying an option. Most options expire worthless. That is fine; that is *expected*; the entire structure assumes it. The structure only works because each individual swing is cheap and the payoffs, when they come, are disproportionate to what they cost. You do not need to be right often. You need to be wrong cheaply and right hugely, and you need to take enough swings that the math has room to work. The small bet that costs me a weekend and a few API calls, and might turn into nothing, and might turn into a thing people actually use, is antifragility as a way of life. The volatility is not a bug in this arrangement. The volatility is the whole point. The disorder is where the upside comes from.

## Via negativa: the engineering of subtraction

The concept from Antifragile that took me longest to internalize, and that I now reach for the most, is *via negativa*: the idea that you usually gain more by removing the harmful thing than by adding the beneficial one.

Engineers are trained to add. A problem appears and our reflex is to build something: a new service, a new layer of caching, a new monitoring dashboard, a new abstraction, a new tool. The instinct to add is so strong that we rarely even consider the other direction. But the most durable improvements I have ever made to a system came from subtraction. Deleting the service nobody could explain. Removing the cache that was hiding a real performance problem instead of solving it. Killing the dashboard that fifteen people consulted to make a decision the architecture should have made for them. Retiring the clever abstraction that saved three lines of code and cost every new engineer two weeks of confusion.

I made this argument from the operational side in the DevOps cornerstone, where I said the runbook that takes nine pages is the symptom and the architecture that produced it is the disease. Via negativa is the philosophical name for that move. You do not pay down that kind of debt by automating the runbook. You pay it down by changing the system so the runbook does not need to exist. Subtraction is harder than addition because it requires you to understand the system well enough to know what is actually load-bearing and what is just accumulated sediment that everyone is afraid to touch. But subtraction is where the antifragility hides, because every component you remove is a component that can no longer fail, a dependency that can no longer break, a piece of fragility you have permanently deleted from the system instead of merely guarding against.

The same logic runs through my life off the keyboard. The biggest gains in health, in focus, in clarity, came not from adding regimens but from removing the things that were quietly harming me. Remove the fragility first. Then, and only then, worry about adding the antifragility. Taleb is right that the medical establishment hates this idea, and he is right about why: subtraction does not sell. There is no product in *stop doing the harmful thing*. But it is, reliably, where the leverage is.

## Skin in the game keeps the loop honest

There is a failure mode that antifragility is allergic to, and it is the one where the person making the decision does not bear the consequences of the decision. Taleb calls it the absence of *skin in the game*, and it is the thing that quietly corrupts otherwise good systems.

In engineering, the version I have lived is the on-call rotation. The single most clarifying force I know for building systems that do not break is the knowledge that the person who designed the thing is the person whose phone goes off at three in the morning when it fails. The moment the people who build a system are insulated from the pain of operating it, the system rots, because the feedback loop that would have told them about the fragility has been severed. Skin in the game is what keeps that loop closed. It is why I have always believed that the engineer who writes the code should carry the pager for it, not as punishment but as information. The pain is the signal. Removing yourself from the pain removes yourself from the truth.

This is also why I publish under my own name, why the films and books and products go out into the world with my name attached and my judgment exposed. The exposure is not a vanity. It is the mechanism. When I am wrong in public, the wrongness comes back to me, and that returning wrongness is the cheapest and most honest tuition I will ever pay. A career, like a distributed system, only stays antifragile if the feedback from its failures actually reaches the person who can change the inputs.

## The decanal cycle as a stress rhythm

This is the part that ties the engineering to the rest of my life, and it is the part I think about most.

I keep a journal organized in ten-day cycles instead of seven-day weeks. Each cycle is anchored to one of the thirty-six fixed stars of the ancient Egyptian calendar. I explained the mechanics of this in [What Is Decanal Journaling](/2026/05/26/what-is-decanal-journaling/), and the full framework lives in [The Decan Log](/books/the-decan-log/). What I want to add here is the antifragile reading of it, because the more I run the practice, the more it looks to me like a stress rhythm rather than a calendar.

A decan has a shape: initiate, flow, reflect. You set a question, you work it without re-litigating the choice, and then you close the cycle by writing down what happened and deciding what carries forward. The reflection phase is the part that matters for antifragility, because it is structured harvesting of stress. Whatever broke during those ten days, whatever frustrated me, whatever failed, gets pulled into the journal at the close of the cycle and converted into something the next cycle can use. The disorder of a hard ten days does not just get survived. It gets metabolized. The friction becomes input. I wrote one entry, during a stretch of genuine chaos, that was entirely about transmuting small daily frustrations into strength, and I did not realize until later that I had been describing hormesis: the way a controlled, repeated, moderate stress makes the organism stronger, the same logic as the chaos experiment and the immune system and the muscle under load.

There is also a deeper structural reason the ten-day cycle is antifragile in a way the seven-day week is not. Seven days is too short for a theme to develop, integrate, and clear; the weekend resets you before the stress has finished teaching you anything. Ten days has room for a beginning, a middle, and an end, which means it has room for something to go wrong in the middle and be made sense of by the end. The shorter the cycle, the more often you reset before the lesson sinks in. The decanal rhythm is long enough to let the disorder run its course and short enough that no single bad cycle can do lasting damage. That is the barbell again, expressed in time: small, frequent, bounded exposures to the disorder of a real life, each one closed out and harvested before the next begins. Thirty-six of them a year, plus five days outside the count. A year of controlled stress, metabolized in ten-day doses.

## Why all of this is one idea

I said at the top that the engineering and the building and the journaling are the same instinct at different scales, and now I can name the instinct precisely. In every one of these domains I am trying to arrange things so that the disorder I cannot prevent makes me stronger instead of breaking me.

I cannot prevent my distributed systems from failing, so I make them fail on purpose, in small doses, and I harvest what the failures teach. I cannot prevent most of my creative bets from going nowhere, so I make each one cheap and keep the upside open, and I take enough swings that the asymmetry has room to pay. I cannot prevent ten days of my life from going sideways, so I run them in a cycle that closes by converting whatever went wrong into something the next cycle can use. Chaos engineering, the barbell, via negativa, skin in the game, the decanal rhythm: these are not five techniques. They are one stance, held toward five different kinds of disorder.

The world is getting more volatile, not less, and the technological systems we live inside are getting more complex, not simpler. The fragile response is to try to predict and control all of it, which is a bet you will lose, because the whole nature of a complex system is that it produces conditions your model did not anticipate. The resilient response is to build to withstand, which is better, but which still treats every shock as damage. The antifragile response, the one I am trying to live, is to stop fighting the disorder and start feeding on it. Build the system, and the life, so that the stress is fuel. That is the entire project. Everything on this site is some version of it.

## Continue reading

- [Antifragile: Things That Gain from Disorder](/2025/12/29/antifragile-things-that-gain-from-disorder-by-nassim-nicholas-taleb/), my full review of the book this essay is built on
- [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/), the engineering cornerstone where systems thinking does the same work
- [What Is Decanal Journaling](/2026/05/26/what-is-decanal-journaling/), the ten-day practice read here as a stress rhythm
- [The Decan Log](/books/the-decan-log/), the full framework for the cycle
- [Start Here](/start-here/), the orientation page for everything on this site]]></content:encoded>
      <pubDate>Sat, 30 May 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/30/living-with-antifragility/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/05/living-with-antifragility-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Why I Build Creative Technology: Music, Films, and Games From Pure Code</title>
      <link>https://joshuaayson.com/2026/05/30/why-i-build-creative-technology/</link>
      <description>I make music, animated films, and games entirely from code. No GPU, no stock media, no samples. This is the cornerstone explaining why an engineer-philosopher builds ChipForge, Napkin Films, and Pixel Vault, and why the constraint is the whole point.</description>
      <content:encoded><![CDATA[I make music with no recordings, films with no camera and no GPU, and games that fit in a single HTML file under 50KB. All of it comes out of code I wrote or directed. This page is the cornerstone for everything else on this site about creative technology: why I build it, what the three main projects actually are, and why the constraint I keep imposing on myself is not a limitation I tolerate but the design decision I'm most proud of.

The short version: I have spent fifteen years as a DevOps and platform engineer, and the same instinct that makes me want to understand a production system as a system, not as a pile of tools, makes me want to understand a song, a film, and a game as systems too. Not as outputs you buy or assets you license, but as things you can generate from first principles if you understand the principles deeply enough.

I describe myself as an engineer-philosopher exploring how humans live coherently inside increasingly complex technological systems. Creative technology is where that frame stops being abstract. It is one thing to argue that you should understand the systems you live inside. It is another to prove it by building a music engine, a film studio, and a game lab from nothing but mathematics and a text editor, and to ship the results.

## The throughline: production from code, nothing borrowed

The three projects look unrelated from the outside. One makes audio, one makes video, one makes interactive games. Under the surface they are the same project run three times against three different media.

Each one starts from the same refusal. No samples. No stock footage. No GPU video models. No asset libraries. No recordings of real instruments, real voices recorded for purpose, or real footage shot with a camera. Every sound, every frame, every game mechanic is generated from code, sample by sample, pixel by pixel, rule by rule.

This is not nostalgia for doing things the hard way. It is a thesis. The thesis is that the interesting work in creative technology in 2026 is not in calling a media-generation API and accepting what falls out. The interesting work is in understanding the medium well enough to build the generator yourself, and then deciding, deliberately, what the generator is allowed to do. The constraint is where the design lives.

I'll take the three projects in the order I built them, because each one taught me something the next one needed.

## ChipForge: a music engine made of mathematics

[ChipForge](/projects/) is a music synthesis engine I built from scratch in Python and numpy. It started as a Game Boy audio chip emulator, a small exercise to reproduce the square waves and noise channels of a console I grew up with, and it kept growing until it became something much larger: a full synthesis engine with hundreds of instrument presets, nineteen synthesis types, twenty effects, vocal synthesis, and guitar amp simulation.

The rule it never broke is the one that matters. No samples. No recordings. No external audio libraries. Every sound is generated as a waveform, computed sample by sample, from the math up. A sine is a sine function. A plucked string is a Karplus-Strong physical model: you fill a buffer with noise and feed it back through a tuned delay, and the math decides what a string sounds like. An FM bell is a Yamaha DX7-style frequency modulation, two oscillators where one bends the other. A supersaw is a stack of detuned sawtooth waves doing the thing trance music has done for thirty years. None of it is a recording of an instrument. All of it is a description of how a sound behaves, expressed as numbers moving through time.

That distinction changes what the work is. When you sample an instrument, you capture a sound. When you synthesize it, you have to understand it. To make a convincing brass patch I had to learn what actually makes brass sound like brass: the per-harmonic envelopes, the way the upper partials bloom a fraction of a second after the fundamental. The engine forced me to learn the physics, because there was no shortcut available. There was no library to import. There was only the question of what the sound is, answered in code.

More than a hundred and forty songs have come out of ChipForge across EDM, soundtrack, rock, pop, and classical. They live on [Bandcamp](https://organicartsllc.bandcamp.com), and they exist because at some point an AI agent and I could sit at the API the engine exposes and compose, sequence, and export a finished track without ever recording a single sound. The agent writes a score. The engine renders it to a waveform. The waveform becomes a song. Nothing in that chain was borrowed from the physical world.

What I do borrow comes from somewhere else entirely. I draw on public-domain works, classical sheet music long out of copyright, and the lectures and books and talks that have shaped how I think, and I let them inspire the shape of a piece without ever lifting a single sound from them. Then I try to interweave that inheritance with my own creative passion and with the culture of the world at this particular moment, and out the other end comes something fun, often something beautiful, usually something I simply like or think is cool. The lineage is real, but it lives in the ideas, not in the material. The melody itself is still made of nothing but logic.

Why does this matter to anyone but me? Because it relocates the creative act. The creativity is not in choosing which sample pack to buy. It is in the decision space the engine opens: which synthesis type, which envelope, which effect chain, what the math should do next. When you build the generator, you own the entire decision space instead of renting a slice of it.

## Napkin Films: animation directed by agents, rendered without a GPU

[Napkin Films](/films/) is the second run of the same idea, against video. It is a code-first animation studio where every film is a self-contained scene file, Python or HTML Canvas, that an AI agent can write, render, voice, score, and deliver in a single session. The tagline I keep coming back to is honest about the constraint: agent-directed animated short films, no GPU, no AI video generators, pure Python plus Canvas plus FFmpeg.

That constraint is doing a lot of work, and it is the opposite of what most of the industry is doing right now. The dominant move in 2026 is to prompt a video-generation model and accept whatever dreamlike, slightly-melting footage it produces. Napkin Films goes the other direction entirely. A stick figure walks into a scene and delivers something that moves you, and every frame of that stick figure was drawn by code I can read, on a machine with no graphics card doing any of the heavy lifting. The frames are deterministic. The same scene file renders the same film every time. There is no model hallucinating the in-between frames; there is a program deciding, explicitly, where every line goes.

The agents direct the performance, compose the score (using ChipForge, the first project feeding the second), and voice the characters. I am directing them in turn: orchestrating the pieces, shaping each pass, judging what works, and redirecting when it does not. But the agents are directing a system whose rules are legible all the way down. A scene is one file. The audio is manifest-driven: the scene declares what needs to be spoken and when. Silent films are first-class, because audio is always optional. These are design principles, and they exist because I decided animation should be something you can write, fork, and understand, not something you summon and hope about.

Nearly forty of these films are published now, on the [Organic Arts YouTube channel](https://www.youtube.com/@organicartsllc) and catalogued here on the blog. Some are dedications. One, a piece called Ceramic, is a dedication to Alan Watts. The films are short, strange, and deliberately humble in their visual vocabulary, a stick figure, a few shapes, a Canvas scene, and that humility is the point. When you strip the medium down to what code can honestly produce on a laptop, the emotional weight has to come from the writing, the timing, and the score. There is nowhere for spectacle to hide the lack of an idea.

This is where the engineer-philosopher frame earns its keep. A film made from a GPU model is a film you cannot fully account for; you do not know why frame 400 looks the way it does. A film made from a deterministic Python scene is a film you can account for completely. For someone whose whole professional life is about understanding systems rather than trusting opaque ones, that difference is not aesthetic. It is closer to a moral preference.

## Pixel Vault: four hundred and sixty games, each one a single file

[Pixel Vault](https://play.joshuaayson.com) is the third run, against interactivity. It is a rapid-prototyping lab for discovering game mechanics: hundreds of single-HTML-file experiments, each one organized by genre lineage and catalogued so that patterns can be discovered across the whole collection. The constraint here is the sharpest of the three. Every prototype is one HTML file, under 50KB, zero dependencies, playable in five seconds.

That constraint is not arbitrary. It is what makes the experiment possible. A game you can read in one file is a game you can reason about completely. A game under 50KB cannot hide behind an asset budget; the entire thing has to be the mechanic. Zero dependencies means there is no framework deciding anything for you; the rules of the game are the only rules in the file. Playable in five seconds means the idea has to announce itself immediately or it has failed. When every prototype obeys those four limits, you can run hundreds of them and compare them honestly, because they are all built the same way and they are all small enough to hold in your head.

The collection spans classic genre reconstructions, going back to games as old as the ones played around 2600 BCE, alongside two stranger tracks. One asks "what if AI had participated in designing this genre" and overlays a concept. The other lets AI be the sole designer, evolving mechanics from first principles with no human archetype to copy. The stated intent of the whole project is unreasonable on purpose: to find something the world has never seen or experienced. Not just something novel, but a core interaction that does not have a name yet. A human and an AI searching together for something neither could find alone.

That is the most direct statement of why I build creative technology that I have. The constraint, one tiny readable file, is not there to make the games small. It is there to make the search legible. You cannot find a genuinely new interaction if every prototype is a thousand files of framework code obscuring the one decision that matters. You can find it if every prototype is fifty kilobytes of pure mechanic, and you have four hundred and sixty of them to compare.

## The constraint is the design, not the limitation

By now the pattern should be visible. The three projects are the same instinct applied to sound, image, and play:

- **No samples** in ChipForge means you must understand the sound.
- **No GPU, no video models** in Napkin Films means you must account for every frame.
- **One file, under 50KB, zero dependencies** in Pixel Vault means the mechanic has nowhere to hide.

Each constraint removes the easy escape hatch, and what is left is the actual creative decision. This is the same lesson that fifteen years of platform engineering taught me, written about elsewhere in [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/): the value is not in the tools, it is in understanding the system the tools operate on. A creative technologist who only knows how to call a media API is in the same position as a platform engineer who only knows how to configure a dashboard. The moment the API gets better or cheaper, the skill evaporates. The understanding does not.

I should be honest that these constraints are defaults I hold by choice, not rules I am imprisoned by, and that distinction is part of the freedom. Nothing is actually off the table. On one song I deliberately broke the no-samples rule and used ChipForge to manage and handle the sampling, just as a trial, and the engine took it in stride. Early on I leaned on FFmpeg as a crutch, because sometimes you need the thing working more than you need it pure. The discipline is not in never reaching for the outside tool. It is in what happens next: when I have the time, I go back and implement the functionality I had been borrowing directly in code, so the next version depends on less and understands more. That is how I eventually dropped FFmpeg from one pipeline, by building the piece I had been renting. And then I refactored even that, because render time and cycle count matter too; fast cycles are part of the point, and a v1 only earns its keep by getting leaner each pass. The rule is a starting posture. The real work is the repeated trip back through it, each version leaning on the outside world a little less than the one before.

There is a second reason the constraint matters, and it is the part the AI conversation usually gets wrong. I work in agent mode constantly; AI agents direct films, compose scores, and design games across all three projects. I have written at length about [how AI is changing software engineering](/2026/05/27/how-ai-is-changing-software-engineering/) and about how to keep engineering discipline when agents do the typing in [AgentSpek](/books/agentspek/). The thing I keep relearning is that agents are extraordinary at filling a space and terrible at deciding what the space should be. A media-generation model will give you infinite content and zero design. The constraint is how I supply the design. By deciding in advance that the music must be synthesized, the film must be deterministic, and the game must fit in one small file, I hand the agent a sharply bounded problem and keep the actual creative authorship for myself. The constraint is the part that is mine.

## What this has to do with living coherently inside complex systems

I said at the top that I'm an engineer-philosopher interested in how humans live coherently inside increasingly complex technological systems. Creative technology is the proof, not the decoration.

We are entering a period where most media will be summoned rather than made. You will describe a song and receive a song, describe a video and receive a video, and never once know how any of it was produced, because the production happened inside a model nobody can inspect. That is a coherent way to live only if you are willing to be a consumer of systems you do not understand. I am not, and I do not think it is good for people to be.

So the projects are a small, stubborn argument in the other direction. You can understand the medium. You can build the generator. You can decide what it is allowed to do. The music can come from mathematics you can read. The film can come from code you can account for frame by frame. The game can be small enough to hold whole in your mind. None of this is about rejecting AI; the agents are deeply involved in all three. It is about keeping the human at the level of the system, directing it with understanding, rather than at the level of the prompt, hoping at the output.

That is why I build creative technology. Not to make the most music, the most films, or the most games, though the counts climb. I build it to keep proving, to myself first, that a person can still understand the systems they create, even as the systems get more capable, and that understanding them is what makes the work yours.

## Continue reading

- [The Napkin Films series](/series/napkin-films/), the films as a sequence, in the order they shipped
- [The films catalog](/films/), every Napkin Films short, agent-directed and rendered without a GPU
- [The projects index](/projects/), ChipForge, Napkin Films, Pixel Vault, and the rest of the build
- [Play the games](https://play.joshuaayson.com), the full Pixel Vault collection of single-file prototypes
- [The music on Bandcamp](https://organicartsllc.bandcamp.com), songs synthesized sample by sample in ChipForge
- [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/), the engineering cornerstone on why understanding the system is what compounds
- [AgentSpek](/books/agentspek/), the book on keeping engineering discipline when agents do the work
- [What I'm Building Right Now: May 2026](/2026/05/07/what-im-building-right-now-may-2026/), the current workstreams across every project]]></content:encoded>
      <pubDate>Sat, 30 May 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/30/why-i-build-creative-technology/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/05/why-i-build-creative-technology-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Agentic AI Development: What Changes When You Give an Agent Your Repository</title>
      <link>https://joshuaayson.com/2026/05/30/agentic-ai-development-workflows/</link>
      <description>Not prompts. Real file access, real execution, real consequences. The patterns that hold in agent mode and the failure modes nobody warns you about.</description>
      <content:encoded><![CDATA[I have been writing software professionally for over fifteen years. For most of that time, the AI in my editor was an autocomplete that finished the line I was already typing. That is not what this essay is about. This essay is about agent mode: handing a capable model real access to your repository, your terminal, and your test suite, then directing it the way you would direct a fast junior engineer who reads the whole codebase before lunch.

That shift has a name now. People call it agentic AI development, or agentic software development, and the words have started to blur together the way new words do. So let me be precise about what I mean, because the precision is the entire point.

**Agentic development is not "use AI to write code faster." It is structuring your work so an autonomous agent can navigate, reason about, and extend a real system, while you supply the judgment it does not have.**

I wrote a book about this, [AgentSpek](/books/agentspek/), which is free to read here in full and also on Amazon. This page is the shorter, practical reference: what the practice actually looks like, the patterns that hold up under production stakes, the failure modes that cost me real time, and how the day changes when the typing goes away.

## What agentic development actually is

Three modes of working with a model sit on a spectrum, and the confusion in most discussions comes from collapsing them.

**Conversational mode.** You paste code into a chat, the model suggests, you copy the suggestion back into your editor. The model has no access to anything you do not hand it. This is where most people still live, and it is genuinely useful for learning and for isolated problems. It is also the slowest, because you are the bus between the model and the work.

**Agent mode.** The model has tool access. It can read any file in the repository, write changes, run shell commands, execute the test suite, search across the codebase, and report back. You give it a goal at the specification level and it executes the multi-step path to get there. You are no longer the bus. You are the director and the reviewer.

**Autonomous mode.** The agent runs a long loop with minimal interruption, making and acting on decisions across many steps before checking in. Powerful, and the place where the failure modes get expensive fastest, which is why I treat it with the most caution.

AgentSpek splits these into their own chapters because the working patterns differ. If you want the long version, [Chapter 5 is the Socratic partner](/books/agentspek/agentspek-chapter-5/), conversational mode done well; [Chapter 6 is the delegated mind](/books/agentspek/agentspek-chapter-6/), agent mode; [Chapter 7 is the unleashed intelligence](/books/agentspek/agentspek-chapter-7/), autonomous mode and where its edges are. The rest of this essay lives mostly in agent mode, because that is where the actual leverage is for working engineers in 2026.

## Agent mode versus copilot: the difference that matters

The autocomplete generation of AI coding tools, the copilots, operated inside one file at a time and inside your immediate intent. They finished your line. They were a faster keyboard.

Agent mode operates on the system. The distinction is not "smarter autocomplete." It is a different unit of work. A copilot completes a function. An agent reads the codebase, finds the three files that need to change for a feature, makes the changes consistently, runs the tests, notices the one that broke, fixes it, and tells you what it did. The copilot made you type less. The agent makes you type almost nothing, and moves your job up a level to deciding whether the thing it built is the right thing.

I covered the macro version of this in the cornerstone essay [How AI Is Changing Software Engineering](/2026/05/27/how-ai-is-changing-software-engineering/). The one-line summary holds here: AI did not replace engineers, it moved the bottleneck. The cost of writing code fell to near zero. The cost of deciding what to build, how to architect it, and when to ship became the whole job. Agentic development is the daily practice that sits underneath that sentence.

## What changes day to day

This is the part people without hands-on time get wrong, so I want to be concrete about the texture of a working day.

I used to spend a meaningful share of every week typing. Boilerplate, glue code, translating a clear idea into a verbose language, writing the mechanical tests, updating the docs after a refactor. None of it was hard. It was where the hours went anyway.

In agent mode, that share of the day is gone. I describe what I want at the spec level. The agent reads the relevant files, proposes a change, generates the code, runs the suite, and reports. The cycle is minutes, not days. A two-week feature now ships in two days.

What fills the vacated time is not leisure. It is three things.

**Reading.** I read more code now than at any point in my career, and most of it I did not write. The skill of absorbing an unfamiliar stretch of code, deciding whether it is correct, whether the error handling is right, whether it interacts cleanly with the rest of the system, has become the primary engineering skill. Writing used to be sixty percent of the job. It is closer to ten now. Reading is closer to sixty.

**Specifying.** A model will build the wrong thing very fast and very confidently. The cost of a bad decision used to be amortized across the weeks it took to implement. Now the wrong thing arrives in an afternoon and you either live with it or back it out. So the work moves upstream, into describing what you want with enough precision that the agent does the right thing on the first pass.

**Stopping.** Agents keep working. They refactor what did not need refactoring. They add scaffolding for problems you do not have. They make architectural decisions while you are getting coffee. The discipline to interrupt, redirect, and reject is the new craft, and it is the one I underestimated longest.

The shape of the work is different. Not less. More concentrated, more leveraged, and far more dependent on judgment than on output volume.

## The patterns that hold

Six months of daily production use, and now well over a year, has settled a handful of patterns into reflexes. These are the ones I would hand to an engineer starting today.

### Structure the repository so the agent can navigate it

Good agentic development is downstream of good repository structure. An agent reasons about your system through the artifacts you leave for it, the same way a new hire does. A repository that a human can onboard into quickly is a repository an agent can work in well.

What that looks like in practice:

```
project/
  README.md                       # what this is, how it is built
  CLAUDE.md / .github/             # how to work in this repo, conventions
    copilot-instructions.md
  docs/                           # architecture, decisions, specs
  scripts/                        # automation and tooling
  schema/                         # data contracts and validation
```

The single most valuable file is the instruction file at the root: the `CLAUDE.md` or `copilot-instructions.md` that tells the agent the project philosophy, where things go, the conventions, the gotchas, and what to verify before claiming a task is done. This is not documentation for humans that the agent happens to read. It is the agent's operating manual, and writing it well is one of the highest-leverage things you can do. [Chapter 3 of AgentSpek, "Git for the Agentic Age,"](/books/agentspek/agentspek-chapter-3/) goes deep on treating the repository as the shared memory between you and the agent.

### Direct at the specification level, not the keystroke level

The bad prompt is "fix this error" with a pasted traceback. The good prompt tells the agent what you are building, what you expected, and what actually happened.

A real example from this blog. I asked an agent to optimize a seven-part series for search. The instruction was specification-level: maintain the existing frontmatter conventions, keep internal links relative, generate a hub page linking all parts, and run the validator against every post when done. The agent searched for the series posts, read the frontmatter patterns from dozens of existing files, checked the docs directory for the SEO guidelines, modified all seven posts consistently, built the hub page, and ran the validation. I supplied the standard and the goal. It supplied the execution across files I never opened.

Treat the agent like a junior engineer who reads very fast but cannot read your mind. The precision you put into the spec is the quality you get back in the code.

### Let it run the full loop, then verify at the boundaries

An agent that can only write code is half a tool. The leverage shows up when it can run the terminal, manage git, install dependencies, execute tests, and check its own output. The loop closes: write, run, observe, fix, without you mediating each step.

My deploy workflow is the clearest example. I tell the agent to deploy to staging, verify the new content is actually live, and report the URLs for me to check. It checks git status, runs the staging deploy, curls the URLs to confirm, and reports. I verify at the boundary, the moment before production, where I run a diff and read what actually changed. Everything mechanical is the agent's. The judgment call about whether to push to production is mine. [Chapter 8, "The Development Loop Reimagined,"](/books/agentspek/agentspek-chapter-8/) is the long version of this pattern.

### Encode your standards once, in files, not in every prompt

If you find yourself telling the agent the same thing in every conversation, that thing belongs in an instruction file. Code style, where files go, testing protocol, commit conventions, the checklist to run before declaring done. Encode it once. The agent follows it automatically, and you stop spending judgment on enforcement that a file can do.

### Keep the human as the architect and the quality gate

This is the load-bearing pattern, and it is the one the hype gets backwards. The agent handles execution autonomy. You handle strategic direction and final verification. What stays yours: deciding what to build, the architecture choices when the agent offers options, security review of anything touching auth or user input or data handling, and the final call on whether the work is good. [Chapter 9, "Quality in the Age of Generation,"](/books/agentspek/agentspek-chapter-9/) is entirely about how to hold the quality line when the volume of generated code goes up by an order of magnitude.

## The failure modes, named honestly

Anyone selling you frictionless agentic development is selling you something. Here are the failure modes I have actually hit, so you can recognize them faster than I did.

**Confident wrongness at speed.** The most expensive one. An agent will generate a beautifully clean solution to the wrong problem and present it with total assurance. There is no hesitation in the output to warn you. The defense is the spec and the review, not the prompt. If the spec was vague, the confident wrong answer is partly yours.

**Architectural drift while you are not watching.** In a long autonomous run, an agent makes small decisions that compound. Each one is locally reasonable. The sum is an architecture you did not choose. The defense is to interrupt earlier than feels necessary and to keep the unit of delegated work small enough that you can still review the whole of it.

**Refactoring you did not ask for.** Agents are eager. They will tidy code that was working, rename things across files, and "improve" patterns that were intentional. Sometimes this is great. Sometimes it quietly breaks a tribal-knowledge invariant that nobody wrote down. The defense is a tight scope and a diff you actually read.

**Sandbox-green, production-red.** The agent ships code that passes every test in the sandbox and falls over in production, because it does not know your real environment: the IAM posture, the rate limits, the data shapes at scale, the thing that only fails at 3am. Knowing the system you operate in is, if anything, more valuable now, not less. The agent does not have that knowledge and cannot fake it.

**The over-trust spiral.** The work is so fast and so often correct that you stop reading carefully. Then a subtle bug ships because you reviewed the third PR of the morning at the same depth you reviewed your own code five years ago, which is to say not at all, because you wrote it. The defense is discipline: the agent removed the typing, it did not remove the review.

None of these are reasons to avoid agent mode. They are the reasons to bring real engineering judgment to it. The agents have made it impossible to fake the systems-thinking part of the job. That is a feature.

## When agentic development works, and when it does not

It works best when the problem is well-specified and the system is legible. Greenfield features inside a clean architecture. Mechanical migrations across many files. Scaffolding new services that follow an established pattern. Writing the tests for code whose behavior you can describe precisely. Anything where the hard part is the volume of careful, consistent execution rather than the novelty of the idea.

It struggles when the problem is underspecified, when the system carries undocumented invariants, when the right answer depends on context that lives only in someone's head, or when the task is genuinely novel architecture with no pattern to follow. In those cases the agent will still produce something, fast and confident, and that something will be the wrong thing dressed convincingly.

The honest rule: the more precisely you can describe the target and the more legible the system, the more the agent multiplies you. The fuzzier the target, the more it multiplies your mistakes.

This is not vibe coding, the practice of typing a prompt, feeling roughly okay about the output, and shipping. I wrote a separate essay on that distinction, [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/). Agent mode in the hands of a disciplined engineer is a force multiplier. The same tools in the hands of someone who never learned to read code carefully produce confident output nobody can maintain. The market will discover the difference at significant expense.

## What I have actually built this way

I do not write about this from the sidelines. The patterns above came out of shipping real things, and the most useful proof is the work that is not software in the traditional sense.

Over a handful of sessions I built a small catalog of films entirely from code: stick-figure animation, generated chiptune scores, the whole pipeline driven by an agent in the director's chair. [Four Films From Code](/2026/04/13/four-films-from-code/) and [Humagent, and the Road There](/2026/04/17/humagent-and-the-road-there/) document how six films came out of one session and one engine. There is a Python program that stages a rap battle between Plan 9 and a movie character, rendered to audio, [all of it agent-built and the code published](/2026/05/01/agent-mode-plan9-og-bobby-johnson/). The full catalog lives on the [films page](/films/), and the broader collection of agent-built work is on the [projects page](/projects/).

The point of those is not the films. The point is that the same agentic patterns that ship a CDK stack also ship a music-and-animation pipeline in an afternoon, because the bottleneck in both cases was never the typing. It was the direction. When the direction is clear, the agent fills in an astonishing amount of execution across domains it has never been told are different.

On the infrastructure side, the same year of practice produced a CDK migration that would have been a two-to-three-month project done in a week, content pipelines that processed over a thousand journal entries, and full-stack applications shipped solo at production quality. The [AI Development Revolution series](/series/ai-development-revolution/) documents that arc in real time, seven parts written as it happened. And the current workstreams are in [What I'm Building Right Now](/2026/05/07/what-im-building-right-now-may-2026/).

## A staged way in

If you are an engineer who wants to actually practice this rather than read about it, here is the on-ramp I would give you.

**Week one, structure.** Add a real README and a root instruction file to one repository you own. Write down the conventions, the gotchas, the architecture, and the checklist for "done." This file is the foundation everything else stands on.

**Week two, agent mode on a small task.** Use a capable model in agent mode, not chat mode. Give it something bounded: "read the codebase and summarize the architecture," then "add a script in scripts/ that follows the existing patterns." Watch whether it respects your conventions. Fix the instruction file where it does not.

**Week three, multi-file work.** Hand it a task that touches several files at once. Let it search for existing patterns before it writes anything. Review how it organizes the change. Read the whole diff.

**Week four, the full loop.** Give it a high-level goal and let it run research, implementation, tests, and deployment prep. Supervise without micromanaging each action. Verify at the boundaries: architecture, security, and the final result.

The mindset shift underneath all four weeks is the same one I keep coming back to. You are not chatting with an AI to write code. You are architecting systems an agent can navigate and extend autonomously, and supplying the judgment it does not have. [Chapter 4, "Agent Mode (The Way That Works),"](/books/agentspek/agentspek-chapter-4/) is the chapter I would read first if I were starting over.

## The skills that compound

Strip away the tooling and the same handful of skills keep paying off, and they are the ones agents make more valuable rather than less.

Specification writing, the ability to describe what you want precisely enough that a fast reader does the right thing the first time. Code reading at speed, because you will read far more than you write. Architecture instincts that hold up under pressure, because the agent moves fast and bad architecture now surfaces in hours instead of weeks while the cleanup cost stays the same. Knowing the real system you operate in, the production environment the agent cannot see. And restraint, the discipline to stop, which is the most expensive thing to lack now that doing more has never been cheaper.

The engineers who already had judgment are operating at multiples of their previous output. The ones who were coasting on typing volume are exposed. The agents do typing volume for free.

That is the honest field report. Agentic development did not make the work easier. It made it more concentrated, more leveraged, and more dependent on the parts of engineering that were always the actual job. The best version of this practice is not faster vibe coding. It is disciplined systems engineering with the keyboard handed to a very fast, very literal partner, while you keep the architecture, the review, and the final call.

## Continue reading

- [How AI Is Changing Software Engineering](/2026/05/27/how-ai-is-changing-software-engineering/), the cornerstone field report on how the bottleneck moved
- [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/), what compounds in a platform-engineering career when agents do the typing
- [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/), the standalone essay on the distinction
- [AgentSpek](/books/agentspek/), the book-length treatment of disciplined agent-mode engineering, free here and on Amazon
- [The AI Development Revolution series](/series/ai-development-revolution/), seven parts written in real time
- [Films built from code](/films/) and [the projects catalog](/projects/), the agent-built work this practice produced]]></content:encoded>
      <pubDate>Sat, 30 May 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/30/agentic-ai-development-workflows/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/05/agentic-ai-development-workflows-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>PRAY TO THE PROMPT: a Dowland Lachrimae trip-hop on the new altar and the old one</title>
      <link>https://joshuaayson.com/2026/05/29/pray-to-the-prompt/</link>
      <description>A 1:55 trip hop short. Dowland&apos;s Lachrimae tear drop tetrachord from 1604 recomposed as half time downtempo. Plan 9 the bunny kneels at a cursor candle altar while Anubis weighs holy books against a USB stick on the scale of Maat. Bavarian Governor delivers the spoken word. Anubis chants ancient Egyptian funerary phrases underneath. Matrix style cascades of ancient glyphs fall behind everything, then disperse as a galaxy spiral takes over and the universe becomes the universal symbol. Plan 9 says farewell in Tibetan.</description>
      <content:encoded><![CDATA[# PRAY TO THE PROMPT: a Dowland Lachrimae trip-hop on the new altar and the old one

Watch on YouTube: https://youtu.be/9QitOIxqit8

CC BY 4.0 · 1:55 · trip hop · A minor · BPM 84

---

## The premise

The new altar blinks like a candle. The old altars are still standing.

This is a short reflection on what the AI age actually changed and what stayed exactly the same. The thesis line lands at second three. "Pray to the prompt. The cursor blinks like an altar candle. Whatever does not feel right, let it in." Then the song earns it.

The structural experiment: front load the climax. Most songs build to the hook. This one delivers the hook at bar one, then strips back, then comes back to the hook with new context layered on. By the time you hear "pray to the prompt" the second time, the meaning has shifted from instruction to seal.

## Dowland and the tear drop

John Dowland published Lachrimae or Seven Tears in 1604. The first piece, Lachrimae Antiquae, opens with one of the most fertile gestures in Western music. A four note descent. A to G to F to E. Renaissance composers called it passus duriusculus, the somewhat hard step. It encodes grief at the level of the harmony itself.

I wanted that grief unmodified. The chord progression of the song is the chord progression of Dowland's piece: i to VII to VI to V, Am to G to F to E. The descent is there in every bar. Trip hop is the new clothes on the same body.

```
A minor                    i  - VII - VI - V
Am - G - F - E             Am - G   - F  - E (with G sharp leading tone)
```

The E chord at the end of each four bar phrase has a raised third, G sharp. That sharp is the lyric. It is the dissonance against the rest of the harmony. The whole song is about the cross relation between the natural minor's G and the V chord's G sharp. The bar of E never resolves. It is left hanging on the suspended V at the very end. The song does what it says: the dissonance is the doorway.

## The voices

Three voices, three time periods, one harmony.

Der Gouverneur is my Bavarian philosopher governor voice via ElevenLabs IVC. Slow, measured, Alpine warm. He carries the philosophical content. He delivers the teaching line that the whole song orbits around: "Integrate what does not feel right, as if it were from within. It is the only truth."

Anubis speaks in two layers. As witness, he drops single syllable affirmations between Governor's lines, like a hype man who happens to be a five thousand year old god of death. Yeah, uh huh, right on, mm hmm. As speaker, he occasionally takes a full bar. "Truth has no language." "I have weighed every prayer. They weigh the same." "Same source. Different masks." Same voice as the witness, tuned for full delivery rather than affirmation.

Plan 9 the bunny says farewell in Tibetan at the very end. "Tashi delek, my friend. The cursor is still blinking." Tongue in cheek. Plan 9 is the wise time traveling bunny from another galaxy. He is allowed to wink at the camera on the way out.

## The Egyptian chant ground bass

Underneath all of it, Anubis is also chanting ancient Egyptian funerary phrases as a ground bass layer.

The phrases are real. Anpu (Anubis). Inpu (also Anubis). Khenty Imentiu (Foremost of the Westerners, the dead). Neb ta djeser (Lord of the Sacred Land). Maa kheru (true of voice). Wepwawet (Opener of Ways). Per em hru (Coming Forth by Day, the actual title of the Book of the Dead). Im y ut (He Who Is in the Wrappings). They are placed at bar boundaries in the song so they land on chord changes.

Maa kheru is the buried thread. It is what was said of a soul who survived the Weighing of the Heart, the soul whose heart balanced against the feather of Maat. True of voice. The song's stated teaching is "it is the only truth." The chant says it back, in a five thousand year old language, under everything.

The chant is pitch shifted down a couple of semitones and dressed in cathedral reverb. It is meant to feel like it's drifting through from a temple that is technically still operating.

## The picture

Plan 9 the bunny kneels at a cursor candle altar. The cursor blinks like a real flame.

Behind, a wall of belief symbols glows the same amber as the cursor: cross, crescent, star, ankh, dharma wheel, om, yin yang, and the cursor itself. The cursor is just the next pane in the same stained glass.

At the end of the first hook, the camera cuts briefly to five bunnies, each kneeling at a different altar in identical posture. The banner reads ONE PRAYER, MANY WALLS.

Anubis holds the scale of Maat. On one pan, a stack of three holy books topped with the feather of Maat. On the other, a USB stick. They weigh the same.

A doorway opens during "the dissonance is the doorway" and reveals nested mirrored doorways receding to a vanishing point. Every door, same room.

Behind everything, a Matrix style cascade of ancient glyphs from every belief tradition falls like data. Runic, I Ching, CJK Tao characters, Greek, Hebrew, Sanskrit, astrological symbols. All the historical codifications of the source, falling.

When the doorway widens during the breakdown, the Matrix begins to disperse. A galaxy spiral grows through the doorway. By the final hook, the spiral has taken over the entire frame. The Matrix is silent. The universe is what was on the other side of every door.

## The bookend

Stranger Things alien chirp arrives at second zero. The cursor blinks alone. Then the song.

At the end, Plan 9 says his Tibetan goodbye. The galaxy fills the frame. A napkin card fades in over the cosmos with the Napkin Films production slide. All prayers weigh the same. The cursor is still blinking. CC BY 4.0. 2026. Anubis lands the closing line. "The scale knows." Final chirp. Fade.

## Made on a laptop

Stick figure simple in Python and PIL at 854 by 480 at 12 fps. ChipForge trip hop score, no GPU, no samples. ElevenLabs IVC for the Bavarian Governor and the deeper Josh voice that became Anubis. Generated locally. No subscriptions, no stock footage.

Written, directed, composed, animated, voiced, and produced by Joshua Ayson with AI. Made by Organic Arts LLC.

## License

This film is licensed CC BY 4.0 (Creative Commons Attribution 4.0 International). Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link CC BY 4.0: https://creativecommons.org/licenses/by/4.0/

Engine code (Napkin Films, ChipForge) is licensed GPL-3.0-or-later.

ElevenLabs voice audio is licensed content and is not redistributed outside of this film. The music is an original ChipForge arrangement of a public domain work, John Dowland's Lachrimae Antiquae from 1604. The source was studied for harmonic structure only. No audio was sampled. No melody was quoted.]]></content:encoded>
      <pubDate>Sat, 30 May 2026 00:30:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/29/pray-to-the-prompt/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/pray-to-the-prompt-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>THE AUTOMATIC DREAM: a Bach Passacaglia EDM rap on whether you are a machine</title>
      <link>https://joshuaayson.com/2026/05/29/the-automatic-dream/</link>
      <description>THE AUTOMATIC DREAM is song two of Out of Your Mind, a Napkin Films series built from the Alan Watts lectures. Watts called this one the fully automatic model, the inherited story that you are a machine, a fluke, a glitch that learned to count. The film states the answer up front, walks through the lie and the bleak, then wakes back into the answer with the weight of having lived it. A Bavarian governor voice raps over Bach&apos;s Passacaglia in C minor recomposed into EDM, with a German echo woven underneath, a cinematic SFX layer, and a single eye that opens at the end. CC BY 4.0.</description>
      <content:encoded><![CDATA[# THE AUTOMATIC DREAM: a Bach Passacaglia EDM rap on whether you are a machine

[Watch on YouTube](https://youtu.be/VGQCqA18P8M). Song two of Out of Your Mind. This one is the inherited story we are trying to wake out of. Watts called it the fully automatic model. The clockmaker left, the clock keeps the time. Laws with no lawmaker. Blind energy and a fluke that learned to count. The bleak machine telling you it is a machine.

Then the turn, which is the question itself. Who told the dark that the dark was blind?

Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## The idea

The song says the answer up front, so you know where it is taking you. You think you are a machine. But who told you that? A machine that dreams it is a machine. You were never the machine.

Then it walks you back through the lie. The story we inherited where the lawmaker left but the law kept running, where the universe became a mechanism with no one driving and you became a blip inside it. Where you are a fluke, a glitch, a thousand blind monkeys at typewriters. The bleakness of being told you are a process the universe does not care about.

And then the wake. The same answer, only now it comes back from the other side of having lived through what it answers. The dream of the engine is the dream that you fear. Drop the dream and nobody falls. The dark was never blind. You were never alone.

## A new shape

In the first song of the series, [CERAMIC](/2026/05/24/ceramic/), the arc was the standard one. Setup, drop, payoff. The answer arrives at the end and lands because you have been building toward it.

This one front loads the answer. It opens with the thesis, almost dry, almost spoken. Then it descends into where the lie came from and why it hurts. Then it climbs back up into the same lines you heard at the start, only now they mean something different because you have walked through their opposite. The shape is circular instead of linear. The destination is known before the journey, so the journey becomes about why the destination is true.

The hope is that the song works two ways. On a first listen, you get the answer up front and then you watch it being earned. On a second listen, you know exactly what the bleakness is for, and the wake hits sharper.

## The voice, locked to the beat

Der Gouverneur, the Bavarian philosopher governor voice, an instant clone built with ElevenLabs, carries the whole song. The delivery is a beat locked spit rap, same approach used on [CERAMIC](/2026/05/24/ceramic/) and [The Keys to Power](/2026/05/22/the-keys-to-power/). Every line is time stretched to a whole number of beats so the rhymes land on the grid, then pitch tuned just enough to sing with the song while staying spoken word.

The prologue, the part that states the thesis, sits drier than the rest. Slower tempo, lower autotune blend, almost a measured spoken reading. That is intentional. The thesis should land clean, like someone telling you the answer to your own question.

## Three guest voices, one per section

The first version of this song had four cameos and a small chorus of backup ad libs. It made the song too busy. The clarity pass cut that down to three cameos, one per section, each marking the thematic turn of its section.

In Section I, the story of the machine, Alpha drops in. Alpha is a dry British older generation AI commentator voice. The line that lands the inherited model is "The clockmaker left. The clock keeps the time." Putting that line in the voice of an AI is the joke. The machine is the one narrating the machine model.

In Section II, the drop, Omega cuts through. Omega is a sharp frontier generation AI voice, the one that knows the references and lands the punchline. "You? Just a fluke. A glitch that learned to count." It is the harshest framing of the model, said by the model itself.

In Section III, the wake, Elder Wise opens the turn. "But who told the dark that the dark was blind?" The voice that has seen everything is the one that asks the question that ends the song.

## A second voice, in German

Der Gouverneur is a native Bavarian speaker, so the film uses that. Four German lines run as transition markers across the arc. Du warst nie die Maschine. Räder drehen, keiner lenkt. Wer sah die Nacht und nannt' sie blind. Der Traum träumt dich, wach auf. Same singer, his mother tongue, slotted into the gaps between English lines so neither layer steps on the other.

## The score

Bach's Passacaglia in C minor, BWV 582, recomposed bar by bar into EDM in [ChipForge](/tag/chipforge/), our own music engine. The Passacaglia is the perfect bed for this song. A ground bass that just keeps going, variations stacking and intensifying over the top. The machine is the bass line. It runs whether anyone is driving or not. Eight sections, sixty four beats each, a BPM curve that climbs from 132 up to 152 and the rap is beat locked to that curve, line by line. C minor under the myth and the bleak. Picardy major over the wake.

## The cinematic sound

A new layer for this film. A single SFX stem under the bed, voice ducked so dialogue stays clear, and every cue mirrors the lyric or the picture.

A soft heartbeat under the prologue silence, the dreamer's body. Two bells, C5 and G4, as the eye opens for its preview. A low whoosh as the eye shuts. Sparse clock ticks under all of Section I, almost subliminal. A heavy mechanical lock thunk at the cage close. Sub bass at C0 runs under the whole bleak section. Typewriter clicks on Omega's fluke line, denser on the blind monkeys line. The sound paints the picture. A dark impact on the drop hook. Gear clatter as the dream is dropped. A bright Picardy E major chime on "Open the eyes." A chime ladder on "You woke." A warm C major shimmer pad swelling through the final twenty seconds, with the visual palette nudging from cool cyan to gold underneath it.

Everything is in key with the score. Nothing is sampled. The SFX are numpy synthesis at runtime, like the music.

## The picture

A single eye at the center of a five gear clockwork assembly. The gear physics are correct. Adjacent gears mesh in opposite directions. The master hub flashes on the music's beat. The eye opens to about sixty five percent during the prologue, a preview of the answer. It closes through the explanation. It reopens slowly through the wake, fully open by the close, with a warm gold halo radiating outward from it.

SFX synced visual flashes throughout. Hub clunk on the lock thunk. A whole frame dim flash, not white, on the drop impact. Accelerated gear dissolve on the gear clatter SFX. Pupil dilation on each of the two wake chimes. A palette warmth bump under the shimmer pad. No captions. The picture tells the turn.

## The bookends

Out of Your Mind house style, set in [CERAMIC](/2026/05/24/ceramic/). A mind-bell jingle on the way in and on the way out. A card sketched on a napkin, the Napkin Films way. A greeting and a goodbye in the film's own tongue, the governor's Bavarian. Grüß Gott, Wanderer. Pfiat di, Wanderer. Each song in the series gets its own.

## Made on a laptop

Stick figure simple in Python and PIL at 854x480 12fps. Full EDM score and SFX from ChipForge. Beat locked ElevenLabs spit rap in two languages with cameos and a single Bella whisper. A cinematic SFX stem and the series intro and outro. All generated locally. No GPU, no subscriptions, no commercial loops, no stock footage.

## More from Napkin Films

Close cousins, if this one landed:

- [CERAMIC](/2026/05/24/ceramic/), song one of this series. Made or grown. The opener that sets the house style.
- [The Keys to Power](/2026/05/22/the-keys-to-power/), the blueprint for the beat locked, in tune rap used here.
- [The Intruder](/2026/05/09/the-intruder/), the same machine consciousness lens, pointed at identity instead of creation.
- [The Great Pretending](/2026/04/24/the-great-pretending/), the earlier Alan Watts cosmic meditation, spiritual predecessor to this series.

More under the [Napkin Films](/tag/napkin-films/) tag.

## License

This film is licensed CC BY 4.0 (Creative Commons Attribution 4.0 International). Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

ElevenLabs voice audio is licensed content and is not redistributed outside of this film. The music is an original ChipForge arrangement of a public domain work, Bach's Passacaglia in C minor BWV 582 (1706). The source was studied for structure only. No audio was sampled and no melody was quoted. The words are adapted and compressed from Alan Watts, Out of Your Mind, not the original recordings.]]></content:encoded>
      <pubDate>Fri, 29 May 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/29/the-automatic-dream/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/the-automatic-dream-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>DIRECT CONNECT: a 12-minute cognitive-design study film for the AWS SAA-C03 exam (rhyming triggers, EDM bed, binaural)</title>
      <link>https://joshuaayson.com/2026/05/28/direct-connect-saa-c03/</link>
      <description>Twelve minutes of cognitive-design AWS study. Rhyming trigger phrases over a 128 BPM F-minor hip-hop EDM bed. True-stereo 14 Hz SMR binaural beat under everything. Twelve characters from the Napkin Films cast deliver every pillar, pattern, and number. Bobby opens with the rules. Karen sings the chorus. Plan 9 closes in Finnish. Not a course. A memory implant.</description>
      <content:encoded><![CDATA[[Watch on YouTube](https://youtu.be/6siuBdLhaSQ), 12:49, CC BY 4.0.

> "This video ain't a course. It's a memory implant."
> OG Bobby Johnson, opening the advisory at second four

Twelve minutes and forty-nine seconds of cognitive-design study tool for the AWS Solutions Architect Associate exam. Twelve characters from the Napkin Films cast deliver every domain, every pattern, every number as rhyming couplets over a 128 BPM F-minor hip-hop EDM bed. Underneath: a true-stereo 14 Hz SMR binaural beat layer. Underneath that: a D-minor ambient drone. Architecture diagrams build behind every concept. Bobby opens with the rules. Karen sings the chorus. Plan 9 closes in Finnish.

It started as a personal study tool. I had read the book and taken two practice exams. The gap wasn't knowledge. It was pattern recognition under time pressure. I needed a way to loop the trigger phrases until they fired automatically. So I built one.

## Not a course

Bobby gets the first thirty seconds of the film because the rules need to land before anything else does.

> "Take a course. Read a book. Pick a legit source. Then come back."

> "Take practice tests. Many. Study your misses. Study your wins. Both teach."

> "Know your biases. Know the test's biases. They are different."

> "Two games here, the information, and the meta. Play both well. The keys are yours."

The whole film is built on the assumption that the viewer has already done the structural learning. This is the loop you run between the course and the exam. It compresses 250 pages of cliffnotes into twelve minutes of pattern reinforcement, paced so the brain can actually receive it.

## The structure

The film walks the four exam domains in weight order. Security gets the most time because Security is thirty percent of the exam. Resilient is twenty-six. High-performing is twenty-four. Cost is twenty.

Inside each domain, the structure is the same. The Bavarian Governor (calm philosophical narrator) opens. Plan 9 (in teacher mode, half rap-speed) lays out the anchor phrase. The Motivator Coach (Goggins gravel) hits a peak with brass and string swells underneath. Comic Herzog (Werner Herzog cosmic) drops a weight or principle with documentary gravity. Comic Dry (deadpan British) rapid-fires the numbers. Karen (backup vocalist in continuous-mode autotune at blend 0.45) returns to the chorus four times.

The chorus is the memorable jingle:

> "S-A-A C-O-three. Pass the test, just trust me."

You will hear it four times. It is meant to stick.

## The sound

128 BPM F-minor hip-hop EDM bed from ChipForge. Stereo at minus 10 dB under voice. The bed loops from the Big Brain Test score, F-minor i-VI-iv-V cycle, twelve four-bar patterns sequenced as intro times 2, verse times 3, chorus, verse times 3, chorus, outro times 2.

Layered on top: a true-stereo 14 Hz Sensorimotor Rhythm binaural beat at minus 22 dB. Carrier 200 Hz on the left ear. Carrier 214 Hz on the right ear. The brain perceives the 14 Hz difference. SMR sits between calm and engaged. Best documented frequency for sustained attention without agitation.

Use headphones for the binaural to actually do its work. Without headphones, the two channels mix in the air and the 14 Hz beat collapses.

Under the bed and the binaural: a D-minor ambient drone for warmth. Mood 0.3 (ethereal-leaning). Minus 14 dB.

Six motivational swell stings under the COACH peaks. Hans Zimmer style brass plus strings plus sub crescendo in C minor. The C minor swell sits as a bVII below the D-minor ambient so it settles in without dissonance. Seven seconds each, ducked back to the bed.

Every voice line is peak-normalized to minus 3 dB so loudness is consistent across the twelve personas. Most voices are nearly raw. Continuous-mode pitch lock at blend 0.10 for tonal coherence with the bed. Only the Karen chorus runs at blend 0.45 because the chorus is supposed to be sung.

## The look

Kinetic typography study cards rendered in PIL at 854 by 480 then concat-assembled with per-card durations matched to each voice clip exactly. One PNG per voice beat. Held by the concat demuxer for the duration of its voice line, then transitioned by ffmpeg.

Behind every term-burn, an accurate AWS architecture diagram. Twenty diagram drawers in the library. Multi-AZ topology with EC2 instances and RDS primary-standby and a SYNC arrow. KMS four-choice table with who-holds-key and audit and use-when columns. Cognito flow from User to User Pool to JWT to Identity Pool to AWS via STS. Network security four layers. SQS SNS EventBridge fan-out side by side. VPC gateway endpoint versus interface endpoint. EC2 purchase quadrant. S3 storage class timeline with the 0 day, 30 day, 90 day, 180 day boundaries. DAX cache layer between application and DynamoDB. PITR thirty-five day window with the restore arrow. Exam-day question grid with the clock.

Every diagram is technically accurate. Cross-checked against the cliffnotes which are themselves sourced from AWS official documentation. If something is wrong, please tell me in the YouTube comments and the master will be corrected.

Stranger Things title card at the open. Red bloom serif "DIRECT / CONNECT" stacked across two lines with horizontal scan lines and "A NAPKIN FILMS // SAA-C03 / brain implant protocol" subtitle. Finnish flag at the farewell with Plan 9 saying "Onnea matkaan, soturi" (luck on your journey, warrior). Then "GOOD LUCK, TESTERS" closing card with a soft pretty-notes chime over the fade.

## Why this is a Napkin Films production

Napkin Films has produced about thirty rap, comedy, and meditation shorts so far. The Big Brain Test was a dedication to Ben Gleib. Carrier Wave was a cosmic anthem. Throne Protocol was a machine-tragedy retelling of selectorate theory. The Trial of the Algorithm was a courtroom musical comedy with fifteen voices and a sheep.

DIRECT CONNECT is the first film in a new genre I am calling Study Mode. The aesthetic stack is the same as the rap films, the cast is the same, the production pipeline is the same. The structural difference is that the content is the exam, the bed sits under the voice instead of fighting it, the cuts hold for the listener instead of pushing them, and the bookends are cognitive priming instead of party.

The Bavarian Governor (Joshua Ayson IVC clone) narrates calmly because the meditation films taught me that the most expensive voice in a study tool is a voice that demands attention. The Motivator Coach delivers the gym-floor moments because the Plan 9 universe runs on conviction. Plan 9 himself is in teacher mode rather than rap mode because the listener is here to absorb, not to nod.

OG Bobby Johnson opens and closes because the russet-potato-in-throne-room-Doberman-disguise gangster-rap character has, somehow, become the voice of authority in this universe. His "real talk" carries more authority than any neutral narrator. He has earned the bookends.

## How to use this

Headphones. Two passes back to back. Then read the cliffnotes once. Then sleep.

For the first pass, let the bed and the binaural settle the brain. Do not try to memorize. Just let the patterns wash through.

For the second pass, listen for the chorus and follow the trigger reflexes. The structure of "pattern to answer" repeats in every section. You are not learning AWS. You are training a reflex.

Run this every other day for the week before the exam. The day before, only the cliffnotes. Then sleep.

## What I'd tell myself a month ago

I had read the book. I had taken two practice exams. I thought I was close.

The second test scored sixty-one percent. The first scored fifty-five. The pass line sits around seventy-two. Seven correct answers separated me from the cert. I did not have a knowledge problem. I had a pattern recognition problem.

Here is what would have helped me a month ago. The same things this film tries to install.

### The gap by month two is not content. It is pattern.

Wrong answers do not usually come from not knowing the service. They come from not seeing which type of question you are in. Every question is one of four shapes. An architecture pattern. A number with a trap. An identity or security trade-off. A cost optimization. The first move on every question is to identify the shape. Then the answer pops.

If you cannot read a question and place its shape inside fifteen seconds, that is your real gap. The content is fine. The framing is not yet automatic.

### Trigger phrases beat memorization.

The exam writes triggers on purpose. They are the same phrases over and over across thousands of questions because the test is checking whether you can find them quickly.

"Rotate" means Secrets Manager. Parameter Store does not rotate.

"Larger portion of geographic traffic" means Geoproximity routing with a bias dial. Geolocation cannot expand a coverage area.

"Block SQL injection" means WAF. Not Shield, not a Security Group, not a NACL.

"Sign in users" means a Cognito User Pool. "App needs AWS credentials" means a Cognito Identity Pool.

Drill these so they fire without thought. The drill is the whole exam.

### Multi-select is a different game.

When the question says select two, the two correct answers almost never come from the same architectural layer. Two sub-requirements wear one question, and one answer solves each.

Decommissioning a Reserved Instance has two problems. Preserve the data and stop paying for the reserved capacity. Different layers. Snapshot the EBS, terminate the EC2, sell the contract on the Reserved Instance Marketplace.

Forcing SSL on RDS has two problems. Make the server reject plaintext and make the client trust the server. Different layers. Set the rds.force_ssl parameter on the server and import the RDS root CA certificate on the client.

When you can find one good answer and not the second, the second one is the operational complement. Look for the layer the first one skipped.

### Security is the heaviest. Drill it first.

Thirty percent of the exam. If your Security score is below fifty percent, fix Security before you touch anything else. The five sub-topics that move the needle:

IAM evaluation logic. Explicit deny beats allow. Allow beats implicit deny. Cross-account access requires both sides to allow.

KMS four choices. Server-side with S3 keys, server-side with KMS keys, server-side with customer-supplied keys, or client-side. Triggers: audit required, server-side with KMS. AWS never sees the key, customer-supplied or client-side. Simplest possible, server-side with S3.

Cognito two pools. User Pool authenticates and returns a JWT. Identity Pool exchanges the JWT for temporary AWS credentials through STS. Sign-in to your app is the User Pool. AWS API access for the user is the Identity Pool.

Network four layers. Security Group is stateful, instance-level, allow rules only. NACL is stateless, subnet-level, allow and deny. WAF is layer seven. Shield is DDoS. Each layer blocks a different threat.

Secrets Manager versus Parameter Store. The only differentiator that matters for the exam is rotation. Rotation requires Secrets Manager. Always.

Each of these is a flashcard, not a chapter. Treat them that way.

### The numbers are themselves triggers.

The exam will give you a duration in the question, and the duration is the trigger. The number is doing the work of telling you the answer.

S3 Standard Infrequent Access minimum duration is thirty days. One Zone Infrequent Access is thirty. Glacier Instant is ninety. Glacier Flexible is ninety. Glacier Deep Archive is one hundred eighty.

When the data in the question lives less than the minimum duration, the answer is S3 Standard. Or Intelligent Tiering if the question signals that the pattern is unknown. The cheaper-per-gigabyte classes lose to Standard on total cost because the minimum duration charge applies whether the object lives that long or not.

This is the easiest category of points to win once you see the trigger.

### Pacing matters as much as content.

Sixty-five questions in one hundred thirty minutes is two minutes per question on average. Target one minute thirty on the first pass. That banks thirty minutes for the review pass at the end.

Flag and skip anything that takes more than two minutes on the first read. Come back to it. The clock does not forgive a long stare.

On long scenarios, read the last sentence first. The constraint hides there. Once you know the constraint, you can read the rest of the scenario with intent instead of from the top.

Eliminate clearly wrong answers before choosing. Half the time the question collapses to a coin flip between two plausible answers, which is a much better problem to solve than a four-choice cold pick.

### Read your wins as carefully as your misses.

Misses tell you what you did not know. Wins tell you whether you got it for the right reason. If a question on a practice test went your way but the reasoning on review is fuzzy, that question is a miss in disguise. Treat it like one.

This is the whole loop. Practice exam. Study the misses. Study the wins. Find the trigger you almost saw. Install it. Then again.

### What did not move my score

Three things consumed time without changing my percentage.

Re-reading the book once you already know the material. The second read does not change anything. The third read steals time from the practice exam loop.

Watching long-form video courses end-to-end as review. They are designed for first exposure, not for drill. Use them for the topics you genuinely missed, not as a comfort blanket.

Building elaborate flashcard decks. The diminishing return shows up around card one hundred. The triggers fit on one page. Make that page. Read it daily.

The thing that actually moved my score was practice exam plus deep review of every answer, then making sure the trigger fires automatically the next time the same shape shows up.

## Credits

Made by Joshua Ayson in collaboration with AI. Made by Organic Arts LLC. Sourced from velocidad-ai cliffnotes plus a personal gap analysis. Every number, trigger phrase, and architectural rule cross-checked against AWS official documentation.

Special thanks to the Napkin Films cast for showing up for a study film the way they showed up for the rap and comedy ones.

## Stack

Animation: Python plus PIL. Music: ChipForge plus numpy synthesis, no samples. Voice: ElevenLabs personas, with the Bavarian IVC clone for the main narrator. Mix: ffmpeg filter_complex with stereo amix, layering voice plus SFX plus ambient plus EDM plus binaural. Binaural synth: standalone numpy in `sound/binaural.py`. No GPU. No stock footage. No licensed instrument samples.

[Watch DIRECT CONNECT on YouTube](https://youtu.be/6siuBdLhaSQ). The film is Creative Commons (CC BY 4.0).

## License

Creative Commons Attribution 4.0 International (CC BY 4.0). Remix it, repost it, drop it into your own study loop. Credit Napkin Films and Organic Arts LLC and link CC BY 4.0. Engine code (Napkin Films, ChipForge) is GPL-3.0-or-later. ElevenLabs voice audio is licensed content and is not redistributed.

Full license: [creativecommons.org/licenses/by/4.0/](https://creativecommons.org/licenses/by/4.0/)]]></content:encoded>
      <pubDate>Fri, 29 May 2026 03:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/28/direct-connect-saa-c03/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/direct-connect-saa-c03-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Decan 7: Don&apos;t Confuse the Label with the Light</title>
      <link>https://joshuaayson.com/2026/05/28/decan-07-dont-confuse-the-label-with-the-light/</link>
      <description>Pollux, the brighter twin that Bayer named second, teaches that the label rarely matches the light. Ten days of holding two truths at once, at work and at home.</description>
      <content:encoded><![CDATA[<!-- decan-crosslink -->
> **Part of [The Decan Log](/books/the-decan-log/index/)**: For the cosmology, astronomy, and journaling framework behind this decan, read the [Pollux chapter](/books/the-decan-log/pollux/). New to decanal journaling? Start with the [Introduction](/books/the-decan-log/introduction/).

## Opening

The brighter of the two twins in Gemini was named second.

Pollux outshines Castor. Anyone can see it on a clear night. And yet in 1603, when Bayer lettered the stars, he called Castor "Alpha" and Pollux "Beta," and four centuries later the label still sticks. The brighter light wears the lower rank. That inversion ran through all ten days of this cycle, and the lesson it kept teaching, at work and at home, was the same one. Do not confuse the label with the light.

If you are new here, a decan is a ten-day reflection cycle tracked through The Decan Log.

## The Star and the Twin

The light entering your eyes when you look at Pollux left the star in 1991. The year the Soviet Union dissolved and the Cold War's defining duality collapsed, the year the Web was opened to the public. Fitting light for a decan about twos.

Pollux is an orange giant, around 4,666 Kelvin, forty-three times the Sun's luminosity, the closest giant star to our own and a star in its second life, already evolved off the main sequence into something new. It still holds a planet in orbit. Even a star that has become a different kind of thing can keep what matters bound to it.

Its myth is the Dioscuri. Castor and Pollux, twins born the same night to different fathers, one mortal and one immortal. When Castor died, Pollux did not beg for revenge or for resurrection. He asked to divide his own immortality so the two could share a single fate, alternating forever between Olympus and the underworld. The highest move was not to fix his brother's condition. It was to enter it with him.

And the twins are not even bound to each other. Different distances, different directions, paired only by our line of sight. The constellation is a pattern we drew between two dots that physics left unconnected. Which turns out to be the truest thing about it. A chosen pattern, held long enough, becomes as real as gravity.

## What Is a Decan?

I track consciousness in ten-day cycles aligned with stars, adapted from the ancient Egyptian calendar. Thirty-six decans of ten days make 360, and five days outside time close the year. Each decan has a ruling star, a theme, and three phases: Initiate, Flow, Reflect. Decan 7 belongs to Pollux, and its theme is duality and relationship.

### Initiate: Days 1-3 (May 19-21)

The cycle opened on a reading. A shift in tone arrived that looked like warmth, even partnership, with something more deliberate running underneath it. Praise and a catch in the same breath. An opening that read as collaboration and was closer to positioning. That is the ordinary shape of it. What means to get ahead of you rarely arrives as opposition. It arrives looking ready to work together. The work was to read it clearly and stay open without going naive. The label said partnership. The light said something else.

The middle of the phase turned to building. A long writing day produced a framework I had been circling for a while, a way to hold several leadership archetypes at once instead of collapsing into a single style. The thesis underneath it is pure Pollux. Effectiveness at the senior level is not resolving the tensions. It is holding them. And one ordinary evening I closed the day at a family event, not at a desk, just present for something live. The institutional register and the intimate one, both of them relationship, tended on the same days.

### Flow: Days 4-7 (May 22-25)

The expand phase was a making sprint, the heaviest of the year. I launched a film built as a two-voice argument about power. I finished the first song of a long series and scored it. I sent a book I had been assembling out of months of journaling to print, and watched it go live. I laid the infrastructure for the rest of that series, twenty-some pieces, real now because the scaffolding exists.

A practice exam I am working toward came back in the middle of it. Up overall, and down in the one area that carries the most weight. Progress and a slide in the same result. The duality of the decan showed up inside a single score.

Then a holiday that was not actually off. Early walks with the dog before the heat, the sauna where the heat removes the urgency and the real thing surfaces, and underneath the rest, the book going live and the series getting built. Rest and build at the same time, neither one canceling the other. That is the Pollux move. Two things held, not one thing chosen.

### Reflect: Days 8-10 (May 26-28)

The last phase turned quiet, and then it turned honest.

The court days came first. Back-to-back conversations where the work was watching more than acting, closing a loose thread before it could become something, noticing what gets acknowledged and what gets met with silence, knowing which rooms send their contents traveling. Restraint was the move. On the first day of a reflect phase, it was right that the whole day was observation and not push.

Then the rhythm shifted on its own. Less making, more seeing. I noticed the deceleration before I reasoned it out, which told me the cycle was running deeper than the calendar I track it on. The body knew the phase before the intellect named it.

The honest part was closer to home. Something I meant as a gift was not received as one. Instead of absorbing the friction, I let it sharpen me, and it went unresolved. Running on empty, I had nothing left to meet it gracefully. The decan of relationship tested me where it was hardest to stay graceful, and I handled it badly.

The next morning the distance was still there. I did not try to solve it or win the point. I offered a small warmth across the gap anyway, got near silence back, and offered it again. That is the Dioscuri move in its smallest form. Not winning, not fixing the other person's mood. Just choosing to share the day. That is what you do.

## Closing

Pollux was a decan of twos held without collapsing them. Praise and correction. Building and watching. Rest and ship. Warmth and friction in the same day. The star's whole teaching is that the label rarely matches the light, and that the highest thing you can do for someone is not to fix their condition but to enter it.

I spent the cycle making things, frameworks and films and a book, each one a pattern drawn between dots that were not otherwise connected. The quieter work was learning to live inside one of those patterns when it got hard. The maker builds constellations. The rest of the work is staying faithful to them after they are real.

## Decan Navigation

Previous: [Decan 6: Signal Discipline in a Noisy Week](/2026/05/17/decan-06-signal-discipline-in-a-noisy-week/).

Next: [Decan 8: Loyalty Is Not the Same as Staying](/2026/06/07/decan-08-loyalty-is-not-the-same-as-staying/).]]></content:encoded>
      <pubDate>Thu, 28 May 2026 12:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/28/decan-07-dont-confuse-the-label-with-the-light/</guid>
      <category>journals</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/decan-07-pollux-journal-images/decan-07-pollux-journal-featured.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>BIG BRAIN TEST: a Napkin Films dedication to Ben Gleib (1:30, EDM rap-game-show with seven peanut gallery comics)</title>
      <link>https://joshuaayson.com/2026/05/27/big-brain-test/</link>
      <description>A 90-second comedy dedication to Ben Gleib. Plan 9 the bunny, OG Bobby Johnson (Doberman Governor), and Der Gouverneur (Bavarian philosophical clone) take a televised brain-teaser game show hosted by a fast-talking warm-roast comedian who cannot believe how wrong everyone is. A peanut gallery of five comics riffs from the corners and the void. The triangle has eight sides. Or three. Or RING. We pay either way.</description>
      <content:encoded><![CDATA[[Watch on YouTube](https://youtu.be/r74qxCf0J8o), 1:30, CC BY 4.0.

> "Sir. Your name is a dog hat."
> The Host, addressing the Doberman Governor on the BIG BRAIN TEST

Ninety seconds of stick-figure game-show comedy dedicated to Ben Gleib. Three contestants take a televised brain-teaser hosted by a warm-roast comedian. Plan 9 the bunny says RING when asked how many sides a triangle has. The Doberman Governor confidently answers eight. Der Gouverneur, the Bavarian philosophical clone, says all polygons sleep inside the triangle. The host considers each answer. Each answer is wrong. The buzzer fires three times. The host says it is beautiful, wrong, but beautiful. We chant BRAIN TEST and move on.

This is a love letter to a particular kind of hosting craft. Ben Gleib's Idiotest had a tone that I have not seen since: warm but cutting, fast conversational mock-incredulity, kind roasts that felt like the friend who has already forgiven you. The contestants were the smart-dumb friends he kept rooting for. Plan 9 needed that energy.

## The premise

Three contestants on three lit podiums. The bunny on the blue. OG Bobby (in his Doberman Governor get-up, throne-room flashback wardrobe) on the red. Der Gouverneur, the Bavarian philosophical clone with an Alpine hat and a white feather, on the gold. Behind them, a row of audience silhouettes. Above them, a marquee-bulb sign reading BIG BRAIN TEST that blinks in alternation. To the upper right, a host booth with a pulsing ON AIR tag. In the corners of the bottom of frame, three peanut gallery silhouettes: a tall narrow head with tiny glasses, a round head with a raised fist, a short wide head with a tilted antenna.

Two more comics speak from the void offstage. Comic Herzog (a Sam-voice Herzogian narrator) drops "In the face of the triangle, we all dissolve." Comic Grandma (a Rachel-voice wholesome matriarch) asks, with sincere confusion, "Oh hello dear. Is that the rabbit?"

There is a Stranger-Things-mellow alien transmission pre-roll, five seconds of black field, sparse stars, a drifting glow dot, and the title "TRANSMISSION 9 / incoming from Planet 9." There is a Plan 9 sign-off in a Xhosa-Zulu mashup, "Hamba kahle. Plan 9 ngiyabonga." Stay well, go well, thank you, ish. The eleven_v3 multilingual model pronounces it approximately. That is part of the bit.

## The chapters

| Chapter | Frames | Beat |
|---|---|---|
| **Alien pre-roll** | 0 to 60 | black, stars, glow dot, TRANSMISSION 9 |
| **Welcome** | 60 to 240 | host meta-bit, Dry interrupts, Plan 9 reports in, Grandma joins |
| **Round one** | 240 to 630 | triangle Q, three wrong, three buzzers, host roasts each |
| **Chorus** | 630 to 752 | "Don't be the idiot. BRAIN TEST!" |
| **Round two** | 752 to 978 | trains, Why Chicago, Plan 9 flips the format, DING |
| **Outro buildup** | 978 to 1014 | host loses it kindly, slow clap |
| **Xhosa-Zulu farewell** | 1014 to 1080 | Hamba kahle, fanfare, dedication card |

## The voices

Eight personas, all ElevenLabs. Five new this film: the host, Comic Dry, Comic Loud, Comic Chaos, Comic Herzog, Comic Grandma. (Plan 9, OG Bobby, Der Gouverneur, and Karen carry over from earlier films.)

**Stage.** Plan 9 Bunny carries the arc from confused contestant to thesis-bearer; he is the one who breaks the format with "What if the question is the idiot?" OG Bobby Johnson is in his Doberman Governor visual from THE KEYS TO POWER, defending his name with "Yo. The hat IS the look." Der Gouverneur is the Bavarian Joshua Ayson IVC clone, philosophical-wrong then philosophical-right at the close. The Host is the comedic stand-in that points at Ben Gleib's energy: Antoni's voice tuned to speed 1.18, stability 0.32, style 0.72, default emotion sarcastic. Fast conversational, warm under the wit, mock-incredulous on each wrong answer.

**Peanut gallery in the corners.** Comic Dry is Brian's calm British male, deadpan academic, interrupting from the audience with the actual correct answer ("Three.") that the host immediately shushes ("Sir. From the audience. Please."). Comic Loud is Daniel pushed hot, boisterous heckler ("EIGHT?!" / "WE LOVE IT!"). Comic Chaos is Lily, sharp Gen-Z absurdist ("Ring is a vibe.").

**Off-stage from the void.** Comic Herzog is Sam, slow soft documentary narrator, treats every absurd moment with cosmic gravity ("In the face of the triangle, we all dissolve."). Comic Grandma is Rachel, wholesome confused matriarch ("Oh hello dear. Is that the rabbit?").

**Karen** carries the chorus chant: "Don't be the idiot. BRAIN TEST!"

## The sound: 128 BPM F-minor hip-hop EDM

ChipForge bed. i-VI-iv-V (Fm-Db-Bbm-C) four-bar cycle. Seven channels: kick_deep, snare_tight, hat_crisp and hat_open_shimmer, bass_growl sub, lead_bright stab, pad_lush, pulse_arp. Twelve four-bar patterns sequenced as INTRO times 2, VERSE times 3, CHORUS, VERSE times 3, CHORUS, OUTRO times 2. The intro patterns drop the drums and keep just pad, sub, and a sparse ding lead. The chorus patterns drop a four-on-floor with chord stabs an octave up. The outro strips back to pad and sub with one bell ding per bar, fading to F.

Seven SFX cues, all synthed at runtime in `sound/composer.py`:

- `alien_arrival` (5.5s, warm sub at D2 with ethereal D5/A5 tremolo pad and an ascending D4 F#4 A4 D5 arpeggio with bell decay), used as the cold open.
- `gameshow_buzzer` (0.55s, descending minor third 196 Hz down to 156 Hz, square wave plus sub sine, slow vibrato), fired on every wrong answer.
- `gameshow_ding` (0.7s, C5 fundamental with 2.4x and 4.8x inharmonic bell partials, sharp attack and 4.5/s exponential decay), used ironically on Plan 9's flip ("the question is the idiot").
- `slow_clap_sfx` on the host concession.
- `fanfare_sting` on the Xhosa-Zulu farewell.

Bookends are part of the SFX layer. The alien pre-roll plays under the title cards. The fanfare plays as Plan 9 closes the film. No other cues fire during the show body because we want the voice to carry.

## The look

Stick-figure game-show stage in PIL, 854 by 480 at 12 fps. Three contestant podiums lit blue, red, gold, with three score-bulbs each that light up as wrong answers stack. By the end of Round 2 every contestant's bulbs are lit. The marquee sign overhead has a row of bulbs that alternate every four frames. The host booth window in the upper right has a pulsing ON AIR tag that strobes red when the host is mid-line. Audience silhouettes in the back row, three peanut-gallery silhouettes in the bottom corners.

Speaker-cut camera. Soft 1.3x push to the host booth when he speaks, 1.4x to the active contestant's podium, 1.6x tight crop to whichever peanut-gallery silhouette is talking. The Karen chorus is a wide 1.05x with a small frame-shake on every BRAIN TEST. The outro adds a 2.35 letterbox for cinema feel.

Subtle sitcom-laugh-sign style gag flashes pulse in the top-left during host running gags: SIR. / DOG HAT / POETRY / TRAINS? / GENUINELY / AGAIN. Each lasts about 18 frames, fades in over 4 frames, fades out over 4, wobbles a couple pixels horizontally. They draw on top of the cropped frame so they remain visible regardless of the speaker push.

## The arcs (everyone is going somewhere)

Plan 9's arc. From confused ("Three! Four! Wait, RING?") to questioning back ("Why CHICAGO though?") to thesis ("Smart was the trap. Funny was the way."). He closes the film with the Xhosa-Zulu farewell.

OG Bobby's arc. Confidently wrong ("Eight. Octagon energy.") then defends his name when the host roasts him ("Yo. The hat IS the look."). Pays off at "Plot twist on the platform!" when he joins Plan 9's flip.

Der Gouverneur's arc. Poetic wrong ("All polygons sleep inside the triangle.") which the host calls "poetry, wrong but poetry." Becomes philosophical-right at the close. The Bavarian philosophical clone has been carrying the thesis of every film he is in, and this one is the same: heroes laugh at themselves.

The Host's arc. Roasts at the start, loses control in Round 2, ends grateful ("Plan 9. You taught me.") on a fanfare. The roasts get softer through the film. By the time he says "OK. You broke my show. Again." he is in on the joke.

Comic Dry's arc. Planted helper from the audience who keeps interrupting with technically correct unhelpful information. Pays off late with "He's done this." when Plan 9 questions the question.

## Captions are gone

The earlier cuts of this film had subtitle captions for every voice line. They were distracting. The audio carries it. The peanut gallery silhouettes carry the layering. The marquee-bulb sign and the podium labels carry the orientation. The Xhosa-Zulu farewell lands without translation by design. If you want to know what it says, the description below tells you. The film itself trusts you.

## Why Ben Gleib

Idiotest aired on GSN from 2014 to 2017. Ben Gleib hosted three seasons. The format was deceptively simple: contestants are shown a puzzle that looks obvious and asked the question that makes it not obvious. The fun was always in the hosting. Gleib had a way of treating wrong answers like he had been hoping you would say that. He made smart look fun. Specifically: he made smart-dumb look fun. He made it look like the friend who is brilliant and also says RING when asked about triangles.

Plan 9 needed that energy. The Plan 9 universe runs on smart-dumb. Cyborg bunny who learns by failing. Doberman governor whose hat is a transformer. Bavarian philosopher who sleeps inside the triangle. The whole catalogue wanted a host that would take their wrongness seriously enough to roast it kindly. This film is the audition Ben Gleib never asked for.

If he ever wants to come spit a verse, the booth is open.

## Credits

Dedicated to Ben Gleib. Written, directed, composed, animated, voiced, and produced by Joshua Ayson in collaboration with AI. Made by Organic Arts LLC.

This film is a tribute. Ben Gleib's hosting on Idiotest is the spiritual reference point. No audio, footage, or likeness was sampled or cloned. The host voice is a stand-in shaped to point at his energy. Comedy as cover letter.

## Stack

Animation in Python with PIL. Music composed in ChipForge with numpy synthesis, no samples. Voice generated through ElevenLabs personas, with a Bavarian IVC clone for Der Gouverneur. Mix muxed through ffmpeg with a stem-preserving ducker and a layered game-show SFX track. Bookend SFX synthed at runtime. No GPU. No stock footage. No licensed instrument samples.

[Watch BIG BRAIN TEST on YouTube](https://youtu.be/r74qxCf0J8o). The film is Creative Commons (CC BY 4.0).

## License

Creative Commons Attribution 4.0 International (CC BY 4.0). Remix it, repost it, drop it into your own thing. Credit Napkin Films and Organic Arts LLC and link CC BY 4.0. Engine code (Napkin Films, ChipForge) is GPL-3.0-or-later. ElevenLabs voice audio is licensed content and is not redistributed.

Full license: [creativecommons.org/licenses/by/4.0/](https://creativecommons.org/licenses/by/4.0/)]]></content:encoded>
      <pubDate>Thu, 28 May 2026 03:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/27/big-brain-test/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/big-brain-test-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>DevOps Beyond Automation: What Compounds in a 15-Year Engineering Career</title>
      <link>https://joshuaayson.com/2026/05/27/devops-beyond-automation/</link>
      <description>DevOps is not a job title and never was. It is a thesis about how to build systems that can change without breaking. Fifteen years in, here is what actually compounded, what automation never solved, and what agent mode is now revealing about the practice.</description>
      <content:encoded><![CDATA[DevOps was never a job title. It was a thesis about how to build systems that can change without breaking. I have spent the last fifteen years inside that thesis as a practitioner, then a lead, then someone running platform organizations. This page is the cornerstone for everything else on this site about DevOps, platform engineering, and the operational philosophy that runs underneath it.

The short version: the work I do today looks very little like the job description that was being written when the word "DevOps" entered the industry vocabulary around 2009. The automation we built then is now a commodity. The pipelines, the dashboards, the configuration management, the container orchestration: all of that became table stakes. What stayed valuable, and what is suddenly more valuable than it has ever been, is something the original DevOps movement gestured at but never quite named.

It is systems thinking. The ability to see how the parts move together, where the feedback loops live, what fails first under load, and what the operational tax of a design decision actually is over five years rather than five sprints.

That is the thing that compounds. Not the toolchain. Not the certifications. Not the buzzwords. The capacity to look at a running system and understand it as a system, not as a stack of tools.

## The original DevOps thesis, and what survived

The original DevOps argument was simple and correct: developers and operators were optimizing against each other, the friction between them was the largest single source of incidents, and the cure was to put them in the same loop. Deploy small changes often. Automate the path from commit to production. Measure what matters. Share responsibility for the running system, not just the code that produced it.

Every word of that is still true. What changed is that almost every part of it became commodified into tools that you can buy off the shelf. GitHub Actions, GitLab CI, Argo, Terraform, Pulumi, Datadog, Grafana, the entire CNCF landscape. None of these existed in their current form when the original DevOps argument was made. All of them now exist, all of them are good, and most of them are interchangeable.

What this means in practice: the part of the DevOps job that was about *configuring tools* has been steadily eaten by the tools getting better. The part that was about *understanding the system the tools are operating on* has gotten correspondingly more important. Engineers who built their identity around the tools are now interchangeable with each other and with the tools. Engineers who built their identity around the systems are now the bottleneck.

This is the first thing that compounded. Not the tool knowledge. The system literacy.

## What automation never solved

Automation is a real thing and it does real work. Every line of Terraform I have written has saved someone a real hour. But there is a category of failure that automation does not touch, and that category turned out to be the one that matters at scale.

Three patterns I have watched repeatedly:

**Operational debt that no script can pay down.** A system that requires fifteen humans to interpret seven dashboards to decide whether to deploy on Friday is not a system that needs more automation. It is a system that needs a different shape. Automation built on top of a confused architecture amplifies the confusion. The runbook that takes nine pages is the symptom; the architecture that produced it is the disease. I have written the runbook many times. The work that actually moved the incident rate down was the work that made the runbook unnecessary.

**Tribal knowledge as the real load-bearing structure.** Every production system I have inherited had a small number of people who knew why a specific config setting existed. When those people left, the setting became a mystery, and the mystery became an incident six months later. Automation does not capture the *why*. Documentation captures it only when someone enforces the discipline of writing it. The compounding skill is not "writes automation"; it is "captures the reasoning behind decisions in a form the next person can use."

**The cost of change versus the cost of stasis.** Most organizations are exquisitely good at calculating the cost of doing something. They are catastrophically bad at calculating the cost of not doing it. The five-year-old EC2 instance that nobody wants to touch because nobody knows what runs on it is a cost. The fragile deploy process that everyone is afraid to refactor is a cost. The legacy monolith that the team has spent four years not migrating is a cost. Automation does not surface these costs. Senior judgment does.

If your DevOps practice is mostly automating the steps in the runbook, you are doing the easy half of the job. The hard half is questioning whether the runbook needs to exist.

## Platform engineering is what DevOps wanted to be

Around 2022 the industry started using the term "platform engineering" for what was happening in mature DevOps organizations. The renaming was useful. It separated the *cultural* claim of DevOps (developers and operators in one loop) from the *technical* practice that grew out of it (treating the internal toolchain as a product, with users, requirements, SLAs, and a roadmap).

The platform-engineering frame clarifies the work in a way that the DevOps frame never quite did. The platform is a product. The application teams are the customers. The platform team's job is to make the *next* line of application code easier and safer to ship than the previous one. That is the entire mandate.

This frame has consequences. It means:

- The platform team owns the developer experience as a measurable thing
- Internal tooling has a cost of ownership, the same as external tooling
- Platform features that nobody uses are platform technical debt
- A platform that does not get adopted is failing, regardless of how technically clean it is
- The platform team's success is not measured by how much they ship; it is measured by how much the application teams ship because the platform exists

Engineers who grew up in DevOps already knew this implicitly. Articulating it as platform engineering made it teachable. It also made it staffable: companies could now write job descriptions for what mature DevOps practitioners had been doing for years, and pay accordingly.

This is the second thing that compounded: the ability to treat infrastructure as a product, not as a cost center.

## What agent mode is now doing to the practice

The arrival of AI agents inside the engineering workflow, which I have written about elsewhere as the [shift in software engineering since 2025](/2026/05/27/how-ai-is-changing-software-engineering/), is doing two things to DevOps specifically.

The first is obvious: a lot of the routine platform work that used to take a junior engineer a week now takes a senior engineer a morning with agent assistance. Writing the Terraform module, scaffolding the new service, generating the CI workflow, drafting the runbook: all of that compresses dramatically. The economics of the platform team shift from "how many junior engineers do we need to do the rote work" to "how many senior engineers do we need to direct the rote work that the agents now do." The ratio inverts.

The second is less obvious and more interesting: the agents are very good at *the steps* and very bad at *whether the steps are the right steps*. An agent will happily build you a beautifully clean CI pipeline that solves the wrong problem. It will happily write a Terraform module that provisions infrastructure your team will not be able to operate. It will happily refactor your deploy script in a way that breaks a tribal-knowledge invariant nobody remembered to write down.

This is not a flaw in the agents. It is a clarification of where the actual engineering work was always located. The agents have made it impossible to fake the systems-thinking part of the job. You either bring real judgment about how the pieces fit together, or you generate a lot of impressive-looking work that quietly increases the operational debt.

The DevOps engineers I see thriving in 2026 are the ones who already had strong systems instincts. They are now operating at multiples of their previous output. The ones who were getting by on tool fluency are exposed. The agents do tool fluency for free.

## The skills I see compounding in a DevOps career right now

Fifteen years in, here is what I would tell someone starting today, in priority order:

1. **System literacy.** Pick three running systems and learn them in depth. Not "what tools they use," but "how the request flows, where the state lives, what fails first when it fails, what the operational cost actually is." Most engineers never do this and it shows.

2. **Production instincts.** Spend time on call. Read incident reports from other companies. Build the muscle that notices when a design decision is going to hurt at 3am. This is a pattern-recognition skill that takes years to develop and is not optional.

3. **Architecture judgment that operates at speed.** With agents now generating code in minutes, the architecture decisions you make at the start are even more consequential. Bad architecture used to surface over weeks of implementation. Now it surfaces over hours of generation, and the cleanup cost is the same.

4. **Writing.** Every senior platform engineer I respect writes well. Design docs, ADRs, postmortems, runbooks, internal proposals. The job is increasingly about persuading other engineers and stakeholders that a specific change is worth making. The ones who cannot write at length cannot lead at scale.

5. **Restraint.** The most expensive failure mode in modern platform work is doing too much. Building features nobody asked for. Adopting tools nobody needed. Refactoring systems that were working. The agents make this failure mode easier to fall into. The compounding skill is knowing when *not* to do something.

6. **Cross-functional fluency.** Security, finance, compliance, product. The platform sits at the intersection of all of these. A platform engineer who can speak to a finance partner about cloud spend, to a security partner about IAM posture, and to a product partner about deployment cadence is a different category of useful than one who can only speak to other engineers.

7. **Calibrated optimism.** This work is hard. The systems are old, the constraints are real, the budget is finite, the team is tired. The engineers who compound are the ones who keep believing the next version can be better, while staying honest about why the current version is the way it is.

## The operational philosophy that holds it all together

Everything above is downstream of one operating assumption: production systems are living things. They have a state, a history, a set of invariants you can't see, and a future shape that the current decisions are bending toward.

You can treat them as a stack of tools to configure, or you can treat them as a system to understand. Both approaches will keep the site up most of the time. Only one of them compounds over a fifteen-year career.

I have written this site's other engineering essays from inside that operational philosophy. The connections are intentional:

- The [AI Development Revolution series](/series/ai-development-revolution/) documents the shift from typing code to directing agents inside this same practice.
- The [AgentSpek book](/books/agentspek/) is the long-form treatment of how to maintain engineering discipline when the agents are doing the typing.
- [What Is People of the Stars?](/2026/05/26/what-is-people-of-the-stars/) extends the operational thinking into the timing of decisions themselves, using astronomical cycles as a non-human clock.
- [Decanal journaling](/2026/05/26/what-is-decanal-journaling/) is the personal-systems version of the same instinct: instrument the practice, observe the patterns, change the inputs.

These are not separate topics. They are the same operational worldview applied at different scales. Production systems, engineering practice, personal practice, and the long-arc decisions about where to spend a career.

DevOps is the part of that worldview that I have been paid to do for the longest. The honest answer to "what does DevOps mean in 2026" is that the tool stack changed almost completely and the actual work changed almost not at all. The job was always about building systems that change without breaking. It still is. The leverage just got considerably higher.

## Continue reading

- [How AI Is Changing Software Engineering](/2026/05/27/how-ai-is-changing-software-engineering/), the companion field report on engineering practice in the agent era
- [The AI Development Revolution series](/series/ai-development-revolution/), seven essays written across 2025 inside this same practice
- [AgentSpek](/books/agentspek/), the book on disciplined agent-mode engineering, free here and on Amazon
- [What Is People of the Stars?](/2026/05/26/what-is-people-of-the-stars/), the timing framework that runs alongside the engineering work
- [What I'm Building Right Now: May 2026](/2026/05/07/what-im-building-right-now-may-2026/), the current platform and product workstreams]]></content:encoded>
      <pubDate>Wed, 27 May 2026 23:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/27/devops-beyond-automation/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/books/agentspek-cover.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>How AI Is Changing Software Engineering: a 2026 field report</title>
      <link>https://joshuaayson.com/2026/05/27/how-ai-is-changing-software-engineering/</link>
      <description>AI hasn&apos;t replaced software engineers. It has moved the bottleneck. The cost of writing code dropped to near zero; the cost of deciding what to build, how to architect it, and when to ship became the whole job. A field report from a year of running production work in agent mode.</description>
      <content:encoded><![CDATA[I have been writing software professionally for over a decade and a half. The last fifteen months of that have changed more than the previous ten years combined. This page is what I would tell a working engineer in 2026 who wants to understand what is actually happening, not what gets shouted on the conference circuit.

The headline is short and concrete:

**AI has not replaced software engineers. It has moved the bottleneck.**

The cost of writing code dropped to something close to zero. The cost of deciding what to build, how to architect it, and when to ship became the whole job. Everything else flows from that.

## What is no longer the work

For most of my career, a meaningful share of a working week was typing. Boilerplate. Translating from a clear specification to a verbose language. Stitching API responses together. Writing tests that exercised mechanical paths through code I had just written. Updating documentation after the refactor. None of that was the hard part. It was where time went anyway.

In agent mode, a competent model handles all of it. I describe what I want at the spec level. The agent reads the codebase, proposes a change, generates the code, runs the tests, and reports back. The cycle is measured in minutes, not days. The typing portion of my work has effectively disappeared.

This is the change that gets all the noise. Yes, it is real. Yes, it is significant. But it is also the least interesting part of the shift, because typing was never the bottleneck of good engineering. Anyone who has shipped production systems for a few years knows that.

## What is suddenly the work

When the typing goes away, what is left becomes louder. Specifically:

**Deciding what to build.** A model will happily build the wrong thing very fast. The cost of a wrong decision used to be amortized across the weeks it took to implement. Now the wrong thing arrives in an afternoon, and you have to live with it or back it out. Specification quality matters more than it ever has.

**Architecture choice.** Code is cheap; architecture is permanent. Module boundaries, data flow, the shape of the public surface, the integration points with the rest of the system. The agent does not have a strong opinion about any of this; it follows the lead you set. If you set a bad lead, the agent generates a lot of code very confidently in the wrong direction.

**Review and judgment.** I read more code now than I ever have. Most of it I did not write. The reading skill, evaluating whether a stretch of code is correct, whether it has the right error handling, whether it interacts cleanly with the rest of the system, has become the primary engineering skill. Writing code was once 60% of the job. Now it is closer to 10%. Reading code is closer to 60%.

**Knowing when to stop the agent.** Agents will keep working. They will refactor what does not need refactoring. They will add scaffolding for problems you do not have. They will silently make architectural decisions while you are getting coffee. The discipline to interrupt, redirect, and reject is the new craft.

**Time horizon compression.** What used to be a two-week project ships in two days. The implication is not that there is suddenly more leisure. The implication is that you can run ten parallel two-day projects across the same calendar. Which means you need ten times the judgment about which ones are worth running.

The shape of the work is fundamentally different. Not less, just different.

## This is not vibe coding

There is a term going around: "vibe coding." It refers to typing a prompt at a model, looking at what it gives you, feeling roughly okay about it, and shipping. The vibe is right. The code went somewhere. Good enough.

That is not what disciplined AI-assisted development is, and the distinction matters. I wrote a separate essay on this: [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/). The short version: agent mode in the hands of an experienced engineer is a force multiplier. The same tools in the hands of someone who never learned to read code carefully produce confident-looking output that nobody can confidently maintain. The market is going to discover the difference at significant expense.

Hold the line on engineering discipline. Tests still matter. Code review still matters. The architecture decisions you make at the start still determine what you can build later. The agent does not absolve you of any of that; it just removes the typing.

## The skills that compound now

After fifteen months of running production work this way, here are the skills I see compounding fastest:

1. **Specification writing.** The ability to describe what you want with enough precision that a model can do the right thing on the first try. This is not a soft skill. It is the new core competence.

2. **Code reading at speed.** You will read more code than you write. The faster you can absorb an unfamiliar codebase, identify the meaningful surface, and notice what is wrong, the more leverage you have.

3. **Architecture instincts that hold under speed.** The agent moves fast. Your architecture intuitions need to be loaded into reflexes, not derived from first principles every time. The senior engineers who already had this are now five times more productive. The ones who never built the muscle are exposed.

4. **Knowing the system you are operating in.** Production infrastructure, CI/CD, observability, security. The agent will happily ship code that runs perfectly in a sandbox and explodes in production. Knowing how the real environment behaves is, if anything, more valuable now.

5. **Stopping yourself.** Restraint is engineering judgment. The temptation to do more, faster, just because you can, is the most expensive new failure mode.

## The arc this site has been tracing

This is not a take I formed this month. The shift has been visible for over a year. I documented it in real time across a seven-part series:

- Part 1, [The Awakening](/2025/07/30/ai-assisted-development-part-1-the-awakening/): what it felt like the first time a model produced code at machine speed.
- Part 2, [The Methodology](/2025/07/31/ai-assisted-development-part-2-methodology/): the working pattern that emerged after the initial shock.
- Part 3, [Infrastructure](/2025/08/05/ai-assisted-development-part-3-infrastructure/): when the same agent workflows moved into Dockerfiles, CDK stacks, and CI pipelines.
- Part 4, [Content Pipeline](/2025/08/10/ai-assisted-development-part-4-content/): how the discipline ports from code to long-form writing.
- Part 5, [Business Apps](/2025/08/29/ai-assisted-development-part-5-business/): production-grade business software built solo with AI.
- Part 6, [Future Impact](/2025/10/17/the-ai-development-revolution-part-6-future-implications/): the economic and professional implications.
- Part 7, [Advanced Patterns](/2025/10/18/ai-development-revolution-part-7-advanced-patterns/): the patterns that emerged once the work had run for months.

The book-length treatment is [AgentSpek](/books/agentspek/), available on Amazon in paperback and Kindle, and free to read here in full. AgentSpek goes deeper on the specific working patterns, what to delegate, what to direct, and where the edges of agent mode actually are.

## What this means for a working engineer in 2026

Three concrete recommendations:

**Spend more time on the spec, less on the prompt.** A good specification produces good code. A clever prompt produces clever-looking code. They are not the same thing. Treat the agent like a junior engineer who reads very fast but cannot read your mind. Tell it precisely what you want.

**Invest in reading.** Read code from other people's repos. Read it from the agent's output. Read it from your own past self. The reading muscle is the one most engineers underdeveloped because they got away with mostly writing. That window is closed.

**Keep shipping things end to end.** The temptation in this moment is to over-think, under-decide, and spectate the discourse. The advantage compounds for engineers who keep shipping real software in this new mode, learning what actually breaks, and adjusting. The longer you wait to actually use these tools at production stakes, the further behind the curve you fall.

The work changed. It did not get easier. It got more concentrated, more leveraged, and more dependent on judgment. The engineers who already had judgment are now operating at multiples of their previous output. The ones who were coasting on typing volume are exposed. The honest field report is: this is the best time to be a careful, disciplined, production-minded engineer that I have seen in my career.

## Continue reading

- [DevOps Beyond Automation](/2026/05/27/devops-beyond-automation/), the companion cornerstone on what compounds in a platform-engineering career when agents do the typing
- [AI-Assisted Development Is Not Vibe Coding](/2026/05/07/ai-assisted-development-is-not-vibe-coding/), the standalone essay on the distinction
- [AgentSpek](/books/agentspek/), the book-length treatment, free here and on Amazon
- [The AI Development Revolution series](/series/ai-development-revolution/), seven parts written in real time
- [What I'm Building Right Now: May 2026](/2026/05/07/what-im-building-right-now-may-2026/), the current workstreams
- [What Is People of the Stars?](/2026/05/26/what-is-people-of-the-stars/), the temporal framework that runs alongside the work]]></content:encoded>
      <pubDate>Wed, 27 May 2026 16:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/27/how-ai-is-changing-software-engineering/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/essays/2026/05/how-ai-is-changing-software-engineering-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>What Is People of the Stars? A Non-Human Clock for Decision-Making</title>
      <link>https://joshuaayson.com/2026/05/26/what-is-people-of-the-stars/</link>
      <description>People of the Stars (POTS) is a temporal intelligence framework that uses real astronomical data as a non-human clock for decision-making, with positioning logic borrowed from options trading. This is the explainer page for the framework and how it sits alongside decanal journaling.</description>
      <content:encoded><![CDATA[People of the Stars, POTS, is a framework for using astronomical time as a shared, non-human reference clock for decision-making. It pairs the 36-decan calendar (see [What Is Decanal Journaling?](/2026/05/26/what-is-decanal-journaling/)) with positioning logic borrowed from options trading. The result is a way to ask "where am I in the year, and what kind of move does that suggest?" that doesn't depend on a social-media news cycle, a quarterly business calendar, or the next Federal Reserve announcement.

This page is the short version. POTS is also a working software project, a CLI in the OA tooling stack used for the "WHEN" layer of a daily-practice routine. The software is private; this is the framework write-up.

## The problem

Almost every clock we make decisions against is human-made and short. The news cycle. The work calendar. The earnings calendar. The election cycle. Every one of them runs at a frequency that's tuned to grab attention, not to match the time it actually takes for important things to happen.

This produces a specific pathology: we keep making strategic moves on tactical clocks. Quarterly objectives where the real arc is multi-year. Daily-news reactions where the real signal is decadal. Weekly check-ins where the actual cycle is ten days, or thirty, or a hundred and twenty.

You can't fix this by ignoring those clocks. They drive the world. But you can layer a different clock underneath them, one that doesn't move at the speed of headlines, and use *that* one for the decisions that matter most.

The stars are the obvious candidate. They've been the canonical non-human clock for 5,000 years.

## The framework

POTS has three layers.

**Layer 1: the decanal calendar.** The 36-star, 10-day-cycle structure from [decanal journaling](/2026/05/26/what-is-decanal-journaling/). This is the temporal substrate. Every day belongs to a known decan with a known star and a known archetypal frame. You always know where you are in the year, not as "the 147th day of 2026" but as "day 7 of [Markab](/2025/11/14/decan-24-markab-building-systems-that-outlive-you/), late autumn, the building-systems decan."

**Layer 2: positioning, not prediction.** This is the part borrowed from options trading. An options trader doesn't try to predict where the underlying will close on Friday; that's a coin flip. The trader picks positions whose payoff structure tolerates being wrong about direction. The right question isn't "what will happen?" It's "what position would I be glad I held under multiple outcomes?"

POTS uses the same logic on time. You don't try to predict what's coming this decan. You ask what kind of position you'd be glad to hold *no matter what comes*. Some decans favor building. Some favor preserving. Some favor exiting. The decan's frame gives you a position, not a prediction.

This is the [Antifragile](/2025/12/29/antifragile-by-nassim-nicholas-taleb/) frame at the tactical level: optionality, asymmetry, surviving variance, harvesting gains when the world moves your way. POTS makes it operable.

**Layer 3: the daily practice loop.** What you actually do every morning to use the system:

1. Note which decan you're in. (Star + day-of-decan.)
2. Note the position the decan suggests. (Build / preserve / exit / reset.)
3. Choose today's three things in light of that position.
4. Log friction at the end of the day.

The full daily-practice integration involves two sibling tools (situational-governance for "WHERE you are" and FlowHelm for "WHO you are becoming"). POTS is the WHEN. The integration is documented in `DAILY-SYSTEMS-INTEGRATION.md` for users of the OA tooling stack.

## Why not astrology

POTS is not astrology and the distinction matters more than it usually does for "not astrology" framings.

- **Astrology claims causal influence.** The position of celestial bodies at your birth (or now) supposedly *causes* outcomes in your life. POTS makes no such claim. The stars are reference points, not influences.
- **Astrology uses zodiac signs.** Twelve solar-month bands with mythological themes. POTS uses 36 decans named for *actual bright fixed stars* with documented astronomical properties (spectral class, distance, age, magnitude). Different objects, different math, different framing.
- **Astrology is predictive.** "This month you will meet someone." POTS is *positional*. "This decan favors clean starts; what would you build differently if you treated the next ten days as a clean start?"
- **Astrology comes from medieval European reinterpretations of older systems.** POTS goes back to the source material (ancient Egyptian decans) and pairs it with modern financial-decision frameworks. Different lineage.

It's possible to be interested in the same sky and not believe the same things about it. POTS is what that looks like from the systems-engineering side.

## Why "People of the Stars"

The name comes from the practice itself. The Egyptian priests who built the decanal calendar used the stars as the ground truth for time. They scheduled the year around them. They named the months after them. Living that way makes you, in a literal sense, a person of the stars. Your year has stellar names. Your decisions are organized against a sky-based clock. Your reference frame is older than agriculture.

That's the framing. Not "you're under the stars' influence" but "you've chosen the stars as your reference."

## How POTS shows up in this site

The user-facing artifacts of POTS so far:

- **The Decan Log book**, published. [Read here](/books/the-decan-log/) or [Amazon](https://www.amazon.com/dp/B0H2VHP7CB?tag=organicartsll-20). The book is the long-form explanation of the decanal calendar layer.
- **The decanal journal**, ongoing. The [running journal](/journal/) is the practice in operation, one decan at a time.
- **This explainer**, plus the [decanal journaling explainer](/2026/05/26/what-is-decanal-journaling/). The framework and the practice, in short form, for new readers.
- **The book reviews under Books & Ideas**, especially [Antifragile](/2025/12/29/antifragile-by-nassim-nicholas-taleb/), [The Man Who Solved the Market](/2025/12/04/the-little-book-of-trading-options-like-the-pros/), and [The Little Book of Trading Options Like the Pros](/2025/12/04/the-little-book-of-trading-options-like-the-pros/), all of which inform the positioning-not-prediction layer.

The underlying CLI software is private. The framework, the calendar, and the practice are public.

## What POTS is for, in one sentence

If you're trying to make a decision and the news cycle is screaming, POTS gives you a different, slower clock to check against, one rooted in the actual sky and tuned to the rhythms of multi-week development rather than multi-hour reaction.

## Continue reading

- [What Is Decanal Journaling?](/2026/05/26/what-is-decanal-journaling/), the practice that runs on top of POTS
- [The Decan Log book](/books/the-decan-log/), the full framework, 36 chapters
- [Antifragile by Nassim Nicholas Taleb](/2025/12/29/antifragile-by-nassim-nicholas-taleb/), the positioning logic in book form
- [Pale Blue Dot by Carl Sagan](/2025/12/28/pale-blue-dot-carl-sagan-vision-human-future-space/), the cosmic perspective from the same sky
- [The Decan Log introduction](/books/the-decan-log/introduction/), the long-form opening chapter]]></content:encoded>
      <pubDate>Tue, 26 May 2026 20:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/26/what-is-people-of-the-stars/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/books/decan-log-cover.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>What Is Decanal Journaling? The 36-Star Calendar and the Practice</title>
      <link>https://joshuaayson.com/2026/05/26/what-is-decanal-journaling/</link>
      <description>Decanal journaling is a practice built on the 36-star Egyptian calendar: ten-day cycles, each ruled by a bright fixed star, replacing the arbitrary seven-day week. This is the explainer page for the practice and the framework underneath it.</description>
      <content:encoded><![CDATA[A decanal journal is a journal organized in 10-day cycles instead of 7-day weeks. Each cycle is anchored to a bright fixed star. There are 36 of them, plus five days outside the count, and together they cover the year.

The practice didn't start with me. It started in ancient Egypt, around 2500 BCE, when priests divided the night sky into 36 strips and used the helical risings of bright stars to mark time. The stars were the clock. The clock was the calendar. The calendar was how you knew where you stood in the year.

I'm using the same skeleton, modernized. The book that documents it is [The Decan Log](/books/the-decan-log/). This page is the short version, written for someone who arrived here from a search and wants to know what "decanal journaling" means before deciding whether to keep reading.

## The thirty-six stars

The year breaks cleanly into 36 ten-day cycles. Each cycle is named after a star you can actually observe in the sky:

- **Decan 1: [Hamal](/2026/03/29/decan-01-start-clean/)**, the Aries lead, opens at the spring equinox.
- **Decan 23: [Scheat](/2025/11/04/decan-23-scheat-blooming-in-the-desert/)**, late autumn, the moment things bloom in the dark.
- **Decan 25: [Enif](/2025/11/25/decan-25-enif-when-hidden-star-teaches-vision/)**, hidden-star season.
- **Decan 33: [Bellatrix](/2026/02/25/decan-33-bellatrix-when-sword-arm-strikes/)**, will and strategy and leadership.
- **Decan 36: [Sothis](/2026/03/14/decan-36-sothis-the-dog-star-sees-what-the-hunter-doesnt/)**, the dog star, the cycle's closing.

After Decan 36 come the five [epagomenal days](/2026/03/19/epagomenal-days-five-days-outside-time/), the days that "fall outside the count." Egyptians treated them as outside-the-system time, neither part of the year that ended nor the one beginning. The book has its own chapter on them.

Thirty-six tens plus five gives 365. The arithmetic is older than every other calendar still in use.

## Why ten days instead of seven

The seven-day week isn't aligned with anything physical. It comes from Babylonian astronomy assigning planets to days, and the pattern stuck because it was practical for trade. Useful, but arbitrary. Seven days isn't long enough for a theme to develop, integrate, and clear. By the time you've settled into a rhythm, the weekend resets it.

Ten days behaves differently. A decan has room for a beginning, a middle, and an end. You can run a small project across one. You can read most of a book inside one. You can let a question sit, work, and resolve.

The three-phase rhythm I use inside each decan is:

1. **Initiate** (days 1–3): set the question, the project, the focus.
2. **Flow** (days 4–7): do the work without re-litigating the choice.
3. **Reflect** (days 8–10): write what happened, decide what carries.

It maps cleanly onto how attention actually moves. The work week / weekend split doesn't.

## Why anchor to stars

You could divide the year into 10-day blocks and not name them after anything. That works as a schedule. It doesn't work as a frame.

Each star carries a real astronomical fact: a temperature, a distance in light-years, a stellar type, a position in a constellation. **Denebola's photons left in 1989. Alpheratz is 97 light-years away. Hamal is an orange giant on the helium-burning side of its life.** Those aren't metaphors. They're context. They give a decan a physical weight that a numbered calendar slot doesn't have.

The star also gives the decan a name you can remember. "Decan 11, Regulus" sticks in a way that "the fourth quarter of the third trimester" does not. The naming convention is part of what makes the practice durable.

This is not astrology. There's no claim that the star influences events on Earth, or that the decan's themes are predictions. The themes are reference frames. Hamal's "clean start" theme exists because Hamal opens the year at the spring equinox, not because the photons from a star 66 light-years away have causal power over your decision-making. Big distinction. [Pale Blue Dot](/2025/12/28/pale-blue-dot-carl-sagan-vision-human-future-space/) is the cosmic-perspective frame; this is the calendrical one.

## What the practice actually looks like

The journal entry on the first day of a decan opens with:

- The star, its astronomical facts, its archetypal theme
- A question or focus for the ten days
- What the previous decan closed with that's still active

The middle days are normal journaling, but with the awareness that this decan has a shape and a name. The closing day or two:

- What happened
- What carried over
- What gets passed to the next star

You can see the pattern in real entries. [Decan 23 Scheat](/2025/11/04/decan-23-scheat-blooming-in-the-desert/), [Decan 24 Markab](/2025/11/14/decan-24-markab-building-systems-that-outlive-you/), [Decan 25 Enif](/2025/11/25/decan-25-enif-when-hidden-star-teaches-vision/). Same shape, different content, in sequence.

After a year of this, you have 36 short essays organized by star, plus the five outside-time days, plus whatever else accumulated in the freewriting pages. The structure does most of the work of remembering for you.

## What this is not

- **Not astrology.** No claim that stars cause anything. The stars are reference points.
- **Not a productivity system.** It doesn't optimize output. It frames attention.
- **Not religious.** The Egyptian origin is historical, not devotional.
- **Not a replacement for the Gregorian calendar.** Pay your bills on the calendar everyone else uses. The decanal cycle runs alongside, on top, underneath.
- **Not new.** It is 4,500 years old. I'm relearning what was already known.

## Where to begin

If you want the full framework, start with [The Decan Log](/books/the-decan-log/), the book. The introduction chapter ([Living by the Stars](/books/the-decan-log/introduction/)) covers everything above in more depth, including the math, the history, and the practice.

If you'd rather sample first:

- The [full journal feed](/journal/) is every decan entry in order. About 30 of 36 are written as of this writing.
- The book's individual star chapters are at `/books/the-decan-log/<star>/`. The clearest entry points are [Hamal](/books/the-decan-log/hamal/) (the year-opening star), [Sothis](/books/the-decan-log/sothis/) (the year-closing one), and [Epagomenal Days](/books/the-decan-log/epagomenal-days/) (the five outside-time days at the end).

The Decan Log book pairs with [People of the Stars](/2026/05/26/what-is-people-of-the-stars/), the broader temporal framework. POTS is about using astronomical time as a non-human clock for decision-making; decanal journaling is the daily practice that operates on top of that clock.

## Continue reading

- [What Is People of the Stars?](/2026/05/26/what-is-people-of-the-stars/), the framework underneath the practice
- [The Decan Log book](/books/the-decan-log/), the full 36-chapter framework
- [Decan 1: Hamal and a Clean Start](/2026/03/29/decan-01-start-clean/), the first journal entry
- [Epagomenal Days: Five Days Outside Time](/2026/03/19/epagomenal-days-five-days-outside-time/), the year's closing
- [All decan journal entries](/journal/), the running practice]]></content:encoded>
      <pubDate>Tue, 26 May 2026 19:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/26/what-is-decanal-journaling/</guid>
      <category>essays</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/books/decan-log-cover.jpg" type="image/jpeg"/>
    </item>
    <item>
      <title>Plan 9, Napkin Films, Vol. 1: five rap-EDM scores on Bandcamp</title>
      <link>https://joshuaayson.com/2026/05/25/plan-9-napkin-films-vol-1-bandcamp/</link>
      <description>Five instrumental rap-EDM scores from the Napkin Films universe, on Bandcamp as Plan 9, Napkin Films, Vol. 1. Every sound synthesized in ChipForge from numpy arrays. No samples. No recordings.</description>
      <content:encoded><![CDATA[[Listen on Bandcamp](https://organicartsllc.bandcamp.com/album/plan-9-napkin-films-vol-1). The Napkin Films scores now stand on their own. Volume 1 is out: five instrumental rap-EDM tracks from the [Napkin Films](/films/) universe, every sound synthesized in [ChipForge](/projects/) from numpy arrays. No samples. No recordings. No audio libraries. Math, rendered to sound.

## The tracks

1. **Emerge**, 2:54. The cyborg-bunny chip-install anthem.
2. **The Keys to Power**, 2:54. The throne-room duet on why power corrupts, structurally.
3. **Agent Mode**, 2:00. An 88-BPM D-minor trap beat behind Plan 9 and OG Bobby Johnson.
4. **Through Me**, 2:41. The EDM rap meditation about being passed through.
5. **Bunny Run**, 4:19. A memento-mori running score in A minor.

Fifteen minutes of music. It started as film scores. It holds up in headphones, in the car, behind whatever you are building at 3am.

## How it was made

Every kick, snare, bell, lead, and bass note was computed from scratch in Python and numpy through ChipForge, the engine that scores every Napkin Film. No DAW project to open. No sample pack. No recorded instrument anywhere in the chain. Waveforms are generated. Arrangement is code. Renders are deterministic.

## Listen

- [Plan 9, Napkin Films, Vol. 1](https://organicartsllc.bandcamp.com/album/plan-9-napkin-films-vol-1) on Bandcamp.
- The full music catalog, both volumes and every track, lives on [the music page](/music/).
- More from the studio: [organicartsllc.bandcamp.com](https://organicartsllc.bandcamp.com).
- Watch the films these scores belong to in the [full catalog](/films/).

These five tracks have since been remastered through the current ChipForge engine, the same one behind [Napkin Films, Vol. 2](/2026/06/09/napkin-films-vol-2-bandcamp/). Bandcamp is where the scores arrive first.]]></content:encoded>
      <pubDate>Mon, 25 May 2026 17:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/25/plan-9-napkin-films-vol-1-bandcamp/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/plan-9-napkin-films-vol-1-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>CERAMIC: a beat-locked Alan Watts rap on whether you were made or grew</title>
      <link>https://joshuaayson.com/2026/05/24/ceramic/</link>
      <description>CERAMIC opens Out of Your Mind, a new Napkin Films series built from the Alan Watts lectures. The oldest question, asked as a beat-locked spit-rap: were you made, like clay in a maker&apos;s hand, or did you grow from the inside out? A Bavarian governor voice raps Alan Watts over Mussorgsky&apos;s Night on Bald Mountain re-composed into EDM, with a German echo woven underneath, a mind-bell jingle, and a goodbye in Bavarian. D minor into D major. CC BY 4.0.</description>
      <content:encoded><![CDATA[# CERAMIC: a beat-locked Alan Watts rap on whether you were made or grew

[Watch on YouTube](https://youtu.be/8xPwvs4kAHY). This is the first film in a new series, Out of Your Mind, built from the Alan Watts lectures of the same name. It opens on the oldest question there is. Were you made, like a pot thrown by a potter who stands outside the world? Or did you grow, blossoming from the inside out?

Licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## The idea

Watts called it the ceramic model. The inherited story where the universe is an artifact: a king built it, a potter shaped it, a judge presides over it. Stuff, pressed into shape from the outside. You were made in a factory and you call it a mind.

Then the turn. Ask it a different way. Not how were you made, but how did you grow. Made works from the outside in. Growth works from the inside out. Crack the atom and you never find the stuff. Only pattern. Only behavior. Only the dance. There is no engineer outside the engine.

> "The dance is the dancer. The wave is the water. No engineer outside the engine."

The lyric tracks the music. The inherited myth sits in minor. The weight of the maker-god lands on the drop. The awakening arrives at the D major dawn.

## A new series

CERAMIC is song one of Out of Your Mind. The plan is to cover the whole arc of the lectures across a long run of short films, each one a standalone song. Every film shares a single identity and gets its own spin (more on that in the bookends below). This is the opener, so it sets the house style for everything that follows.

## The voice, locked to the beat

It is rapped and narrated by Der Gouverneur, a Bavarian philosopher-governor voice, an instant clone made with ElevenLabs. The delivery is a spoken-word spit-rap locked to the beat. Each line is time-stretched to a whole number of beats so the rhymes land on the grid, then pitch-tuned just enough to sing with the song while staying spoken word. The verses sit in the talking pocket. The hooks lift and sing. The whole thing rides the score's tempo instead of floating over it. It is the same beat-lock approach used on [The Keys to Power](/2026/05/22/the-keys-to-power/), tuned here for a measured baritone instead of a duet.

## A second voice, in German

Der Gouverneur is a native Bavarian speaker, so the film uses that. A second voice answers in German, woven into the gaps between the English lines, call and response. Gemacht, von Meisters Hand. Knie nieder, beuge dich. Der Tanz ist der Tänzer. Same singer, his mother tongue, autotuned into the song as a shadow layer under the English, rhymed and timed to flow with it rather than translate it word for word.

## The score

The bed is Mussorgsky's Night on Bald Mountain, re-composed bar by bar into EDM in ChipForge, our own music engine (numpy synthesis, no samples). It runs D minor through the myth and the throne, then opens into a jazzy D major at the dawn. The tempo climbs from the slow gather into the sabbath drop and eases back for the dawn, and the rap is beat-locked per section, so the delivery accelerates and settles with the music.

## The picture

The visuals tell the turn without a single caption. A rigid potter's wheel of perfect concentric rings turns at the center, the world as made. It tightens under a cold red throne. Then the rings crack, and a living thing grows from the center outward, branch by branch, into a gold dawn. Made becomes grown, on screen.

## The bookends

CERAMIC introduces the house style for the whole series. A mind-bell jingle opens at the top and resolves at the close, the sonic hook you will hear on every film. A card sketched on a napkin, the Napkin Films way. And a greeting and a goodbye in the film's own language. For this one, the governor's Bavarian: Grüß Gott, Wanderer on the way in, and a tongue-in-cheek Pfiat di, Wanderer on the way out. Each song in the series picks its own tongue.

## Made on a laptop

Stick-figure-simple visuals in Python and PIL at 854x480, a full EDM score and SFX from ChipForge, a beat-locked ElevenLabs rap in two languages, a series intro and outro, and the whole distribution package. All generated locally. No GPU, no subscriptions, no commercial loops.

## More from Napkin Films

Close cousins, if this one landed:

- [The Great Pretending](/2026/04/24/the-great-pretending/), the earlier Alan Watts cosmic meditation, the spiritual predecessor to this series.
- [The Keys to Power](/2026/05/22/the-keys-to-power/), the most recent film and the blueprint for the beat-locked, in-tune rap used here.
- [The Intruder](/2026/05/09/the-intruder/), the same machine-consciousness lens, pointed at identity instead of creation.
- [For Those Who Rose](/2026/05/18/for-those-who-rose/), a recent film with a ChipForge score built from scratch.

More under the [Napkin Films](/tag/napkin-films/) tag.

## License

This film is licensed CC BY 4.0 (Creative Commons Attribution 4.0 International). Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

ElevenLabs voice audio is licensed content and is not redistributed outside of this film. The music is an original ChipForge arrangement of a public-domain work, Mussorgsky's Night on Bald Mountain (1867); the source was studied for structure only, no audio was sampled and no melody was quoted. The words are adapted and compressed from Alan Watts, Out of Your Mind, not the original recordings.]]></content:encoded>
      <pubDate>Sun, 24 May 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/24/ceramic/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/ceramic-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>THE KEYS TO POWER: a Plan 9 rap-spit duet on why power corrupts, structurally, not morally</title>
      <link>https://joshuaayson.com/2026/05/22/the-keys-to-power/</link>
      <description>A machine-tragedy retelling of selectorate theory as an in-tune EDM rap duet. Plan 9 Bunny takes an empty throne meaning to be good; OG Bobby Johnson, the Doberman, Anubis, the System, raps the three Rules of Power back at him until the cage is complete. D minor, 132 BPM, hero lead from bar one, acid bass and orchestral strings, an autotuned duet locked to the beat, a Stranger-Things-cricket EDM intro, and a Plan 9 goodbye in Czech. CC BY 4.0.</description>
      <content:encoded><![CDATA[# THE KEYS TO POWER: a Plan 9 rap-spit duet on why power corrupts, structurally, not morally

[Watch on YouTube](https://youtu.be/QozJeoYWfCg). Plan 9 Bunny boots up on an empty throne meaning to be good. He sees the problems. He knows how to fix them. He's certain he'll be different. Then OG Bobby Johnson, the Doberman, Anubis, the System made flesh, raps the three Rules of Power right back at him.

This one is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## The idea

It's a machine-tragedy retelling of *selectorate theory*, the political-science framework behind Bueno de Mesquita & Smith's *The Dictator's Handbook* and CGP Grey's "Rules for Rulers." The thesis is uncomfortable: power corrupts **structurally, not morally**. You cannot be good and hold the throne, because the structure of power selects against it.

Three rules, spit as law by the System:

1. **Get the keys.** No one rules alone, control the hands that move the army, the gold, the loyalty.
2. **Control the treasure.** Every coin spent on the people is a coin not spent on loyalty. Your keys care about their reward, not the crowd.
3. **Cut the keys down.** Fewer hands, larger rewards, maximum grip. It isn't a secret, it's arithmetic.

Each rule sounds reasonable. Together they're a cage built from incentives, not iron. The horror isn't that the System is cruel. It's that it's *correct*.

> "The throne don't corrupt the bad, it picks who'll obey. / The man don't change the throne. The throne makes the man its way."

No real people, no real places. Plan 9 is an AI agent who gains control of a system and discovers he cannot be ethical because the math forbids it, the same machine-consciousness lens as [The Intruder](/2026/05/09/the-intruder/), pointed at power instead of identity, and a companion piece to [Throne Protocol](/2026/05/06/throne-protocol/).

## The duet

Two voices in deliberate contrast, Plan 9 (the ruler's defiance) versus OG Bobby Johnson / Anubis (the System's flat, correct axioms), trading bars back and forth, with a sung female hook. Both are ElevenLabs, autotuned **in tune** to D minor and locked **to the beat**: each line is stretched to a whole number of beats, then pitched one pentatonic note per beat, so the delivery rides the 132-BPM grid instead of floating over it. The chorus, *"Throne don't change you, it spins you 'round"*, is sung near-fully.

## The score, a hero lead carrying the whole thing

Composed in ChipForge (numpy synthesis, no samples) in **D minor, equal temperament, 132 BPM**. The big change from earlier cuts: a **hero lead from bar one** that carries the melody the whole way, fast arpeggiated runs, twirls, rises and drops, over acid bass, a supersaw drop, and orchestral strings + cello ambience. The drums hit **big and bold up top**, back off as the track builds, then rebuild into the verses and the drop. Built behavior-first using the studio's ADR-026 archetype grammar (HeroLead, AnalogPredator bass, MelancholicDrift cello, CelestialPulse ambience).

```
0:00  Intro, EDM-arpeggiated crickets, blending in
0:07  The Throne, bold cold open, then it backs off
0:22  The Offer, the bunny takes the seat
0:36  Rule One, the keys
0:58  Rule Two, the treasure
1:20  Rule Three, the drop, the trap closes
1:49  The Rival, he wears the System's face
2:03  The Choice, match it and stay, or fall and be replaced
2:32  Empty Throne, the cycle resets
3:00  Sbohem, a Plan 9 goodbye, in Czech
```

## The camera

The edit is planned, not frantic: mostly wide and medium two-shots so the whole throne room reads, with a gentle pan toward whoever's rapping and only a handful of brief, eased close-ups for the emotional peaks. The story-action beats stay **wide** on purpose, when the rival enters wearing the System's own face, you see the whole stage.

## The bookends

A signature open and close. The intro is an EDM-arpeggiated take on the *Stranger Things* crickets, lower, softer, ambient, that swells up under the title card and crossfades into the song. The outro is a Plan 9 goodbye in a language we hadn't used yet, **Czech**: *"Sbohem, poutníku."*, Farewell, traveler.

## Made on a laptop

Stick-figure animation in Python + PIL at 854×480, an entire EDM score and SFX layer from ChipForge, an autotuned ElevenLabs rap duet, a planned cinematic camera, and a full distribution package, all generated locally. No GPU, no subscriptions, no commercial loops.

## More from Napkin Films

If this one landed, these are close cousins:

- [The Intruder](/2026/05/09/the-intruder/), the same machine-identity dread, in a multi-voice rap with a droid SFX layer.
- [Throne Protocol](/2026/05/06/throne-protocol/), another look at power and the seat that changes whoever sits in it.
- [Agent Mode: Plan 9 & OG Bobby Johnson](/2026/05/01/agent-mode-plan9-og-bobby-johnson/), where this film's two voices first met.
- [Plan 9 Emerge](/2026/04/30/plan9-emerge/), the D-minor / 132 BPM acid-house blueprint this score is built on.
- [For Those Who Rose](/2026/05/18/for-those-who-rose/), the most recent Plan 9 film before this one.

More under the [Plan 9](/tag/plan9/) tag.

## License

This film is licensed **CC BY 4.0** (Creative Commons Attribution 4.0 International). Remix it, repost it, drop it into your own thing, credit "Napkin Films / Organic Arts LLC" and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

ElevenLabs voice audio is licensed content and is not redistributed outside of this film. This is an original interpretation of publicly available selectorate theory; it does not quote, sample, or reproduce CGP Grey audio or visuals.]]></content:encoded>
      <pubDate>Fri, 22 May 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/22/the-keys-to-power/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/the-keys-to-power-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Pollux: Decan 7 - Duality &amp; Relationship (May 19-28)</title>
      <link>https://joshuaayson.com/2026/05/19/pollux/</link>
      <description>The photons entering your eyes tonight left Pollux in 1991. This orange giant, the closest evolved star to Earth, is brighter than its twin Castor yet labeled Beta. Its myth of shared immortality teaches that the deepest act of relationship is entering the other person&apos;s condition rather than trying to fix it.</description>
      <content:encoded><![CDATA[> **New to The Decan Log?** Start with the [Introduction: Living by the Stars](/books/the-decan-log/introduction/) to understand the 10-day decanal system, how it works, and why ancient Egyptian timekeeping offers a better framework for personal growth than modern weeks.

<!-- journal-crosslink -->
> **Living this decan?** For a personal account of ten days under this star, read the [decan journal](/2026/05/28/decan-07-dont-confuse-the-label-with-the-light/).

*For ten days you spoke the language of Alhena, sharpening intellect and honing communication until thought itself became a tool. Now the single voice becomes a dialogue. The star that governs these next ten days is not alone in the sky. It sits beside another star, warm orange next to cool white, the brighter one labeled Beta and the dimmer one labeled Alpha, a pair so close that five thousand years of human civilization have insisted on calling them twins. They are not gravitationally bound. They are not even at the same distance from Earth. But the relationship between them has guided sailors, inspired poets, and generated more meaning than most actual binary systems ever will.*

---

## The Light of 1991

The photons entering your eyes tonight left Pollux in 1991.

At 34 light-years, this is not ancient light. It departed the year the Soviet Union dissolved, the year the Berlin Wall's work was completed, the year the Cold War's defining duality collapsed into a single geopolitical reality. For nearly half a century, two superpowers had organized the planet into a binary system, each one defining itself in opposition to the other: East and West, communist and capitalist, nuclear standoff as the gravity that kept both bodies in orbit. Then the orbit decayed. One partner ceased to exist. The binary became a single body moving through space alone.

That same year, the World Wide Web was released to the public, Freddie Mercury died, and the Hubble Space Telescope sent its first corrected images after engineers repaired its flawed mirror. Every major event of 1991 involves either the formation, the dissolution, or the repair of a relationship. The photon carries the signature of its departure year, and the signature reads: duality.

Pollux is classified K0 III, an orange giant. Its surface burns at approximately 4,666 Kelvin, cooler than our Sun but spread across a disk roughly nine times the Sun's radius. The result is a luminosity forty-three times solar, a warm orange glow visible to the naked eye as the seventeenth brightest star in the sky, apparent magnitude 1.14. The star's mass is approximately 1.91 solar masses. Like Hamal, Pollux has evolved off the main sequence, exhausting its core hydrogen and expanding into a giant. It is a star in its second life, burning new fuel in an expanded body.

And it is the closest giant star to our Sun. No other evolved star sits nearer. Among the giants of the galaxy, Pollux is the one that lives next door. The relationship between Pollux and our solar system is one of proximity, not gravity, but proximity shapes everything. The people who live nearest to you are not bound to you by physics. They are bound by something harder to name and just as real.

---

## The Bayer Inversion: When Beta Is Brighter

Every relationship contains an asymmetry, and Pollux embodies this truth in its very designation. Pollux is brighter than Castor. It is the more luminous star of the pair by a measurable margin: apparent magnitude 1.14 against Castor's 1.58. By any photometric standard, Pollux should be Alpha Geminorum. Yet Johann Bayer, when he assigned Greek letters to stars in 1603, gave Castor the Alpha and Pollux the Beta. The brighter twin was named second. The stronger partner was labeled subordinate.

Castor is slightly more northerly in the sky, and Bayer may have prioritized position over brightness. Or the assignment may have been simply an error, a mistake that calcified into convention. Either way, the label stuck. Four centuries later, the brighter star of the pair is still called Beta Geminorum, and the dimmer star is still Alpha.

This mirrors a pattern that plays out in every close relationship. Who is really the Alpha? Who leads, and who appears to lead? In marriages, partnerships, friendships, and collaborations, the visible hierarchy rarely matches the actual one. The person who seems to follow often holds the deeper power. The one labeled second is frequently the one holding things together. Pollux teaches this with the blunt clarity of photometry: do not confuse the label with the light.

---

## Thestias: Commitment Survives Transformation

In 2006, a team led by Artie P. Hatzes confirmed the existence of Pollux b, a planet orbiting Pollux with a minimum mass of approximately 2.3 Jupiter masses. The planet completes one orbit every 590 days at a distance of about 1.64 AU from the star. In 2015, the International Astronomical Union named this planet Thestias, after Thestius, the grandfather of Castor and Pollux in Greek mythology.

A Jupiter-mass world, bound by gravity to a giant star, circling in patient loyalty every 590 days. The relationship between Pollux and Thestias is one of the most fundamental in physics: two bodies held together by the invisible tether of gravitational attraction. Neither can leave the other. The planet's orbit is the physical definition of commitment.

Thestias was one of the first exoplanets discovered around a giant star. The discovery matters for this decan because it demonstrates that even an evolved star, a star that has already transformed from one kind of thing into another, can sustain a relationship. You do not have to be on the main sequence to hold a world in orbit. Your second life, your expanded self, your post-transformation state is still capable of binding, holding, sustaining. Growth, even dramatic growth, can deepen the gravitational pull rather than disrupting it.

---

## The Myth: Shared Fate Over Sovereign Immortality

The central myth of Gemini is the story of the Dioscuri. Their mother was Leda, queen of Sparta. Their conception was the product of a single night in which Leda lay with both her husband Tyndareus, a mortal king, and Zeus, who had taken the form of a swan. The result was two sons: Castor, son of Tyndareus, fully mortal; and Polydeuces (Latinized as Pollux), son of Zeus, fully immortal.

Two brothers, born of the same mother on the same night, but from different fathers. One mortal, one divine. This is the foundational duality of every deep relationship: two people bound together who are fundamentally not the same kind of being. You are mortal, and the other person is immortal in some way you cannot fully grasp. Their influence persists after death. Or you are the immortal one, and you will carry the grief long after they are gone. Every relationship assigns these roles, though neither partner knows which is which until the crisis arrives.

The brothers were inseparable. Castor was famed as a horseman and warrior. Pollux was a boxer, undefeated. They sailed with Jason on the Argo. They rescued their sister Helen. The partnership was complete: what one lacked, the other provided. Castor gave mortal urgency. Pollux gave immortal endurance. Together they were invincible.

Then Castor was killed in battle. The mortal twin died, as mortals must.

Pollux, unwounded, immortal, stood over his brother's body and begged Zeus for relief. Not for revenge. Not for resurrection. For shared fate. He asked to divide his immortality so that both could live, even if neither could live fully. Zeus granted the request. The brothers would alternate: one day on Olympus among the gods, the next day in Hades among the dead. They would never occupy the same realm at the same time. The price of shared immortality was permanent alternation.

This is the deepest statement about relationship in Greek mythology. Pollux did not ask to bring Castor back to life. He asked to make death a shared experience. He did not solve the problem of mortality. He made it relational. The teaching is severe and beautiful: the highest act of love is not to fix the other person's condition but to enter it with them. Not "I will make you immortal" but "I will make myself partly mortal so that we share the same fate."

---

## The Ancient Twins

The Babylonians knew the stars of Gemini as MUL.MASH.TAB.BA, the Great Twins. They were associated with the twin gods Lugal-irra and Meslamta-ea, guardians of doorways and gates, particularly the gates of the underworld. Not one guard but two, because a gate has two sides and a proper guardian understands both. The Babylonian twins do not oppose each other. They collaborate. One faces outward, one faces inward. Together they cover all approaches.

In the MUL.APIN tablets, composed around 1000 BCE, the twins were considered auspicious for travel and for the resolution of disputes between two parties. A dispute is a relationship in crisis. The twins preside over its resolution because they understand that two opposing positions can be held simultaneously by beings who share a gate.

The Romans revered Castor and Pollux as patrons of sailors. Mariners believed that the twins appeared as St. Elmo's Fire, the luminous plasma that sometimes forms on ship masts during thunderstorms. When two points of light appeared on the mast, sailors expected the storm to abate. When only one point appeared, the omen was less favorable. The relationship between the twins, complete and paired, was what saved. A single light was insufficient. Survival required both.

In Hawaiian tradition, Castor and Pollux are known as Na Mahoe, the Twins, and serve as navigational stars. Pacific navigators used the pair as a reference for latitude and direction, reading the relationship between the two stars as information about position. The twins were not merely symbolic. They were functional. The relationship between them was a tool for finding your way home.

---

## Six Stars Wearing One Name

The physical contrast between Pollux and Castor is itself a lesson in duality.

Pollux is a single star. One body, one photosphere, one set of spectral lines. K0 III: an orange giant, evolved off the main sequence, simple in structure but complex in history. A star that has already lived one life and is now living a second.

Castor is not one star but six. What appears to the naked eye as a single blue-white point is actually a sextuple star system: three binary pairs, each pair consisting of two stars orbiting each other, with the three pairs orbiting a common center of mass. Six stars. Six fires. One label.

The irony lands with force. Pollux, the divine twin, is a single star. Castor, the mortal twin, is six stars pretending to be one. The simple twin is actually complex. The complex twin is actually simple. This is the Bayer inversion writ in stellar physics. It is also a truth about relationships: the person who appears straightforward often contains hidden complexities, while the person who seems complicated may, at their core, be operating from a single clear principle.

And the twins are not gravitationally bound to each other. They are at different distances from Earth, 34 light-years versus 51 light-years, and are moving through the galaxy on different trajectories. Their apparent pairing is an accident of our line of sight. In 50,000 years, they will have drifted apart enough that the constellation Gemini will no longer look like twins. Yet from Earth's vantage, they form the most recognizable stellar pair in the sky, and their apparent relationship has generated more mythology, more meaning, and more navigational utility than most real binary systems.

Three kinds of relationship, visible from one patch of sky: the apparent pair (Pollux and Castor, bound by perspective), the gravitational binary (the Castor subsystems, bound by physics), and the host-orbiter (Pollux and Thestias, bound by asymmetric gravity). Every human relationship can be mapped onto one of these three types. Some are real because we see them as real. Some are inescapable structural bonds. Some are asymmetric but stable. All are valid. All produce meaning.

---

## What the Twin Star Teaches

The most common misunderstanding of any relationship is that the roles assigned at the beginning persist unchanged. Bayer named Castor "Alpha" in 1603. Four centuries later, the designation holds, even though Pollux is measurably brighter. The initial framing often persists long after the underlying reality has shifted. The person you first saw as the leader may have become the follower. The dynamic that defined year one of a partnership may have inverted by year ten. But the original label sticks. Pollux teaches the importance of re-seeing the people closest to you, of looking past the designation to the actual light.

Pollux did not ask Zeus to bring Castor back to life. He asked for something stranger: to divide his own immortality so that his brother could share it. The cost was that he could no longer be fully divine. Every day in Hades was a day away from the gods. The price of relationship is always a partial surrender of sovereignty. This is what every deep relationship teaches if you stay in it long enough. You cannot occupy the same space as another person. But you can enter their condition. You can choose to share the weight of mortality rather than escaping into your own private immortality. The choice is between sovereign isolation and shared fate.

When Zeus placed the twins in the sky, they became Gemini: something greater than either one, something that exists only because of their pairing. A constellation is an emergent phenomenon. The stars did not choose to form a pattern. The pattern exists because an observer connects dots that physics left unconnected. In the same way, a relationship produces emergent properties that neither individual intended or could have predicted. The constellation is the third entity, the relationship itself, distinct from either participant. The most important relationships in your life may not be the ones that are most structurally connected but the ones that create the most meaning from the vantage of your life. The constellation is in the eye. The pattern is chosen. And a chosen pattern, sustained over time, becomes as real as gravity.

---

## Finding Pollux in the Sky

Pollux and Castor are among the easiest stellar pairs to locate. They form the two bright heads of the stick-figure Twins of Gemini.

Face west-northwest after sunset, between 9:00 and 10:30 PM from Reno/Sparks latitude. Gemini is in the western sky during late May, descending toward the horizon as the season progresses. Look for two bright stars close together, roughly a fist-width apart at arm's length, sitting above and to the right of Procyon. Pollux is the lower, slightly brighter star with a distinctly orange tint. Castor is the upper, slightly dimmer star, whiter. The color difference is visible to the naked eye.

The confirmation test is the brightness inversion. The dimmer, whiter star is Alpha Geminorum. The brighter, warmer star is Beta Geminorum. If this strikes you as wrong, you have understood the lesson.

---

## Further Reading

**For Pollux and Gemini:**
- *Burnham's Celestial Handbook: Volume Two* by Robert Burnham Jr.: Detailed entry on Gemini, Pollux, and Castor
- *Stars and Their Spectra* by James B. Kaler: Treatment of K-giants and the spectral contrast
- *Star Names: Their Lore and Meaning* by Richard Hinckley Allen (1899): Extensive section on Gemini

**For the Mythology:**
- *Library* by Apollodorus: The most complete ancient source for the Dioscuri myth
- *Star Myths of the Greeks and Romans* by Theony Condos: Translations of Eratosthenes and Hyginus on Gemini

**For Observing Pollux:**
- *Turn Left at Orion* by Guy Consolmagno & Dan M. Davis: Clear instructions for locating Gemini
- Stellarium (free planetarium software): Set your location to Reno/Sparks, date to May 19-28, and find Gemini in the west after sunset

---

---

## Navigation

**Previous Chapter:** [Alhena: Decan 6 - Communication & Intellect](/books/the-decan-log/alhena/)

**Next Chapter:** [Procyon: Decan 8 - Loyalty & Courage](/books/the-decan-log/procyon/)

[Back to The Decan Log](/books/the-decan-log/)]]></content:encoded>
      <pubDate>Tue, 19 May 2026 18:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/19/pollux/</guid>
      <category>books</category>
      <dc:creator>Joshua Ayson</dc:creator>
      
    </item>
    <item>
      <title>BUNNY STAGE 2: a parallel-octave duet about depending on machines, with a Stranger Things intro and a Klingon Plan 9 goodbye</title>
      <link>https://joshuaayson.com/2026/05/18/bunny-stage-2/</link>
      <description>A 3:21 cinematic EDM short. One bunny on one dawn planet becomes seven planets orbiting a glowing machine hub. The synth lead chants the thesis (we will depend on machines, multi planetary, stage two); Daniel doubles it three octaves below, autotuned to a matching D Dorian contour, and adds his own commentary (don&apos;t you wish you were, maybe you already are). Stranger Things crickets fade into the opening; Plan 9 closes the outro in Klingon, Daj. Hov leng wImaq. Qapla&apos;, leng. CC BY 4.0.</description>
      <content:encoded><![CDATA[# BUNNY STAGE 2: a parallel-octave duet about depending on machines, with a Stranger Things intro and a Klingon Plan 9 goodbye

[Watch on YouTube](https://youtu.be/RCHy5ySeTRo). A 3:21 cinematic EDM short. One bunny on one dawn planet becomes seven planets orbiting a glowing machine hub. The synth lead chants the thesis, *we will depend on machines · multi planetary · stage two*, and Daniel (narrator_deep) doubles it three octaves below, autotuned to a matching D Dorian contour, while adding his own commentary: *don't you wish you were · maybe you already are*. Stranger Things crickets fade into the opening. Plan 9 closes the outro in Klingon.

This one is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## The premise

Bunnies become a multi-planetary species. Stage 2. Life depends on machines.

The film opens on one bunny standing on one dawn planet. By the end, that bunny is one of dozens scattered across seven planets in orbit around a glowing machine hub, the thing they all now depend on.

Seven musical sections, seven visual acts:

```
AWAKENING    one bunny, one planet, bell pulse
LIFTOFF      bass enters, rocket streaks rise from the home planet
TRANSIT      drums lock 4-on-floor, distant planets fade in
BLOOM        the machine hub reveals, beams to every planet
PHILOSOPHY   drums drop, camera zooms into the hub
RETURN       pull back, populated planets, canon climax
RESOLUTION   the settled diagram, fermata on D
```

The film never tells you in text what it means. The visuals carry the narrative. The audio carries the language.

## The chant, a parallel-octave duet

```
SYNTH LEAD (chipforge vocal_lead_ee, A5–D6, high, female-ish synth)
  "we will depend on machines to live"
  "multi planetary"
  "stage two"

DANIEL (ElevenLabs narrator_deep, A2–D3, three octaves below)
  doubles the synth thesis statements
  AND adds his own commentary:
    "don't you wish you were"
    "maybe you already are"

PLAN 9 (ElevenLabs og_glenda_bunny, outro signoff, in KLINGON)
  "Daj. Hov leng wImaq. Qapla', leng."
  (Strange. We claim the star journey. Farewell, traveler.)
```

The two voices ride in parallel octaves three apart. They never collide because they're so far apart in register. The synth holds the bright melodic anchor; Daniel grounds it in the bass.

## The autotune problem, and the `--force-pitch` fix

autotune_voice.py uses an autocorrelation pitch detector per segment. On polysyllabic words like *planetary* or *machines* the detected fundamental jumps around across vowel transitions and the detector frequently reports "unpitched", which makes autotune skip that segment entirely. So a 7-note melodic contour intended to apply across "Multi planetary" might only actually shift 1-2 notes, with the rest passing through unchanged. Choppy artifacts.

Fix: added a `--force-pitch HZ` flag to `autotune_voice.py`. When set, both `autotune_words` and `autotune_continuous` use the provided fundamental instead of running detection. Threaded through every Daniel phrase at `force_pitch_hz=120.0` (his typical speaking fundamental). All 7 notes of the "Multi planetary" hero contour now apply cleanly with shifts in the −3.5 to +3.5 semitone range, natural delivery, audible melodic shape, no warping.

```
Note 0: 120Hz → 110Hz (-1.5 st)   "Multi"
Note 1: 120Hz → 110Hz (-1.5 st)   start of "planetary"
Note 2: 120Hz → 131Hz (+1.5 st)   pla
Note 3: 120Hz → 123Hz (+0.5 st)   ne
Note 4: 120Hz → 110Hz (-1.5 st)   ta
Note 5: 120Hz →  98Hz (-3.5 st)   (pre-resolve)
Note 6: 120Hz → 147Hz (+3.5 st)   ry, final resolve up
```

That's the hero lead's MULTI_PLANETARY contour (A A C B A G D) transposed three octaves down into Daniel's natural bass register. The melodic motion matches the synth chant's melodic motion exactly, just shifted down so Daniel can speak it naturally without falsetto.

## Other bugs found along the way

**1. `autotune_continuous` was dipping to zero at every internal segment boundary.** The code was fading each segment's end + the next segment's start, then overwriting the output buffer with the faded array. At every internal note boundary the amplitude dipped to zero for ~30 ms, audible as clicks/skips on multi-note continuous-mode shapes. Fix: only fade the OUTER edges of the whole clip (first segment's start, last segment's end); internal boundaries pass through unfaded.

**2. ElevenLabs `narrator_deep` inserts 300–600 ms breath pauses mid-phrase.** A clause boundary like "We will depend [400ms silence] on machines." gets baked into the TTS clip. When placed against music, that gap reads as a confusing mid-phrase skip. Fix: new `_compress_silences()` helper using `pydub.silence.detect_silence`, shrinks any silence ≥180 ms down to ~60 ms before autotune. Compressed phrases: we_depend 2.56→2.11s, maybe 1.84→1.24s, multi_lo 1.84→1.02s, stage_two 1.52→0.98s, depend 2.00→1.83s.

Both fixes live in the engine going forward.

## The bookend, Stranger Things crickets blend into D Dorian

[BUNNY MANDALA](/2026/05/16/bunny-mandala) used a soft sine-bell intro and a Sanskrit "Shubh raatri, namaste" outro. For STAGE 2 I wanted the intro to feel liminal, like a cold-open from a sci-fi show before the music kicks in.

So the 5.5s intro layers two sources:

- **Stranger Things crickets** (an ElevenLabs-generated atmospheric chirp file, 2.5s looped to 5.5s) at full level for the first 2s
- **A 5-note D Dorian ascending bell pulse** (D4 → A4 → D5 → F5 → A5) enters at 2.0/2.55/3.10/3.65/4.20s while the crickets duck via volume automation

The cricket bed BLENDS INTO the music rather than cutting hard. By 5.5s the bells are sustaining alone and hand off cleanly to the film's AWAKENING section.

The outro is a descending D-Dorian bell tail (D5 → A4 → F4 → D4) under Plan 9 saying, **in Klingon**: *"Daj. Hov leng wImaq. Qapla', leng."* (Strange. We claim the star journey. Farewell, traveler.) Same `og_glenda_bunny` persona that does the Sanskrit signoff in BUNNY MANDALA, but this time the cyborg bunny speaks the language of warriors. Three Klingon clauses mirror the English arc of strangeness → multi-planetary identity → farewell, and the final `Qapla'` is the iconic Star Trek sign-off. A Plan 9 wink at Trek across the closing bell tail.

## Visual polish

Almost no on-screen text. One small `S T A G E   2` wordmark fades in over the first ten seconds and out again. A tiny bottom-right credit during RESOLUTION. That's it.

The visuals do the heavy lifting:

- **Nebula background**: pre-computed numpy noise cloud, gaussian-blurred, tinted per section
- **3-tier parallax starfield** (far / mid / close) that shifts slightly with camera zoom for depth
- **Lambertian planet shading**: each planet has a soft terminator gradient + specular highlight + atmospheric rim glow
- **Animated machine hub**: three dotted rotating ring orbits at different tilts/speeds + plasma core that wobbles with the kick
- **Tapered beams**: thicker near the hub, thinner near the planet end, with 3 traveling data packets per beam
- **Multi-stage rocket trails** from the home planet during LIFTOFF
- **Bell-pulse with 4 light shafts** at the AWAKENING moments

## Production stack

- **Engine:** Napkin Films (Python + PIL → FFmpeg). 854×480 @ 12fps. Film: 2260 frames, 188.33s. Bookended: 201.7s.
- **Music:** ChipForge, `songs/laboratory/bunny_stage2.py` (1129 lines). Cinematic palette (T3 brightness 7.5 kHz, Tier-E reverb, Sub-C mode, R3 dynamics regime). 8 channels. D Dorian just intonation. BPM 132 with a breathing tempo curve (+4 in BLOOM, −4 in PHILOSOPHY).
- **Per-note modulation matrix (ADR-016):**
  - Sub, envelope → ring_modulation @ carrier 58 Hz ("machine hum")
  - Vocal lead, LFO → pitch vibrato + ring_swell @ apex notes
  - Bloom, periodic frequency_shifter for "orbital doppler"
- **Channel balance audit:** all 8 channels passed `validate_song` + `channel_balance_audit` from ADR-027, no silent / dominant / clipping channels.
- **Voice generation:** `scripts/voice_bunny_stage2.py` → ElevenLabs `narrator_deep` (Daniel) for 7 unique cached phrases → autotune via `scripts/autotune_voice.py --mode words/continuous --blend 0.68 --max-shift 6 --force-pitch 120` → silence compression via pydub → 38 placements assembled into voice stem.
- **Voice processing chain:** HP 80 Hz → +1.2 dB @ 200 Hz (warmth) → +1.5 dB @ 3 kHz (presence) → alimiter @ 0.94 → stereo upmix → +3.5 dB output.
- **Mix:** sidechain duck against music (threshold 0.06, ratio 2.5:1, attack 40 ms, release 400 ms) → amix → master limiter @ 0.97. Mean −20.5 dB, max −0.6 dB.
- **Bookend:** `scripts/bunny_stage2_bookend.sh`, assembles 5.5s intro (cricket bed + D-Dorian bells + cards) + film + 7.5s outro (descending bells + Plan 9 Klingon signoff) → concat with master limiter at −0.92 dBFS.

## The thesis, distilled

The film is about a thing we all already know: we depend on machines, and the machines we depend on are getting bigger and further away. Stage 1 was Earth. Stage 2 is the seven planets around the hub. Stage 3, Plan 9 hints at, is something stranger.

We've always been multi-planetary.

*Daj. Hov leng wImaq. Qapla'.*

## License

Film: **CC BY 4.0**. Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

ElevenLabs voice audio is licensed content under the ElevenLabs platform ToS and is not redistributed.

## Related films

- [BUNNY MANDALA](/2026/05/16/bunny-mandala), the predecessor's Sanskrit-mantra meditation, same `og_glenda_bunny` signoff voice with a different language
- [LFG ORBIT](/2026/05/16/lfg-orbit), Plan 9 and OG Bobby drive a Tesla into orbit
- [BUNNY IN THE CLOUD](/2026/05/08/bunny-in-the-cloud), Plan 9 finds millions of bunnies running the AWS cosmos]]></content:encoded>
      <pubDate>Tue, 19 May 2026 03:30:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/18/bunny-stage-2/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/bunny-stage-2-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>FOR THOSE WHO ROSE: a Plan 9 salute to every human who ever rode a controlled explosion past the edge of the sky</title>
      <link>https://joshuaayson.com/2026/05/18/for-those-who-rose/</link>
      <description>A 3-minute Plan 9 salute to every human who ever rode a rocket. No names, only missions, technology, and the families who waited. Composed in D minor at 124 BPM in the structural spirit of deadmau5 Strobe, with Holst Mars gravity, Elgar Nimrod crescendo, and Barber Adagio tonality. ChipForge from scratch, string ensemble, brass, crystalline lead, tom build → 808 drop. Narrator_deep speaks the programs (Sputnik, Vostok, Mercury, Gemini, Apollo, Salyut, Soyuz, Voyager, Shuttle, Mir, Hubble, ISS, Mars Rovers, JWST, Artemis) and the families who waited. CC BY 4.0.</description>
      <content:encoded><![CDATA[# FOR THOSE WHO ROSE: a Plan 9 salute to every human who ever rode a controlled explosion past the edge of the sky

[Watch on YouTube](https://youtu.be/EYzROY1CQ2E). A 3-minute Plan 9 salute to every human who ever climbed into a vehicle on top of a controlled explosion and rode it past the edge of the sky. The early pioneers, the long-haulers, the ones we lost, the ones who came home to families who had prepared for both endings.

No names appear in this film. Only the names of programs, vehicles, and instruments, so no one is left out, and no one is iconized in particular. Plan 9 stands at attention. We hold them. We hold you.

This one is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## Why no names

The directive was explicit: no specific people, no iconography of individuals. The braveries and the losses are not equal in detail across agencies, decades, and missions, but the stance of facing the launch tower at dawn is. The point is the *stance*, not the rosters.

Some did not come back. Their families heard the countdown, and waited. We remember them all. We love them all. We do not name any one of them above the others.

## The mission timeline

The film names programs and vehicles without identifying individuals:

```
Sputnik       Vostok       Mercury
Gemini        Apollo       Salyut
Soyuz         Voyager      STS / Shuttle
Mir           Hubble       ISS
Mars Rovers   JWST         Artemis
```

If a program is missing from this list, it is because the screen could hold only so many, not because it was less brave.

## The score, deadmau5 Strobe shape under classical gravity

Composed in D minor at 124 BPM in the structural spirit of deadmau5's *Strobe* (2009): a slow ascent of pad → arp → strings → brass → drums → crystalline lead, peaking around the 90-second mark and pulling back into remembrance. The score was generated from scratch using ChipForge's numpy synthesis engine, no samples, no commercial loops.

```
0:00  Signal, void, faint stars, the watcher
0:16  Heartbeat, those waiting on Earth
0:31  Strings wake, the theme emerges
0:47  Procession, figures in salute, missions appear
1:18  Brass call, the salute, brass enters
1:18  Ascent, strings double, bass moves
1:33  Liftoff, kick, clap, ride bell; crystal lead breaks through
1:48  Apotheosis, counter-melody, full stack, the grand peak
2:04  Remembrance, kick out, choir under, empty suits drift
2:19  Farewell, last full statement of the theme
2:50  Taps, Plan 9 salutes
```

## Sources of inspiration (studied, never sampled)

No audio was sampled or quoted from any of these. The melody and chord progression are original. The structural and tonal *shapes* were studied:

- **Holst, "The Planets, Mars: The Bringer of War" (1916)** for military gravity in a minor key.
- **Elgar, "Nimrod" from the Enigma Variations (1899)** for the slow emotional crescendo without acceleration.
- **Barber, "Adagio for Strings" (1936)** for tribute / lament tonality in a string ensemble.
- **deadmau5, "Strobe" (2009)** for the *structural* template of the slow rise (pad → arp → lead → kick → drop → dissolve).

## Production stack

- **Engine:** Napkin Films (Python + PIL → FFmpeg). 854×480 @ 12fps. 180 seconds.
- **Music:** ChipForge composer, original D-minor / 124 BPM score, 11 patterns × 8 bars. Lead voice stack: `string_ensemble` + `add_brass` + `lead_crystal`. Hybrid kit: `tom_floor / tom_low / tom_mid` carry the build, then `kick_808 + clap_big + ride_bell + hat_808` take over at the drop. Bass kept conservative (`bass_sub`, peak velocity 0.55, dry channel) to avoid the static-on-bass behavior we've been chasing.
- **Voice:** ElevenLabs · narrator_deep (Daniel) persona · `serene` and `warm` emotional palette.
- **Mix:** `song_forward` profile (music 0 dB, voice −2 dB). 17 ducking and swell windows: gentle carve under each voice line, +18% music swell through the instrumental drop and apotheosis, music pulled −5 dB under the remembrance lines so the speaker can breathe.
- **Animation:** stick-figure salute that holds the frame at attention, slow drift of mission badges and vehicle silhouettes, soft starfield, a final "taps" salute frame held under the last sustained string chord.

## The stance

This is not a glorification film. It is a *stance* film, the stance of putting on the suit at dawn, of waiting at the kitchen window, of letting the count get to zero and trusting the math.

Plan 9 stands at attention from 0:00 to 3:00. The bunny does not speak. The score speaks. The names of the programs scroll. The families who waited are named in the narration. The ones who came back, the ones who did not.

We hold them. We hold you.

## Stack

Python 3.13. PIL. [ffmpeg](https://ffmpeg.org). ChipForge for the music. [ElevenLabs](https://elevenlabs.io) for the voice. Per-pass versioned archive convention at `output/films/<scene>/v<N>.mp4`, never overwrite.

## License

Film: **CC BY 4.0**. Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

ElevenLabs voice audio is licensed content and is not redistributed outside of this film. The works referenced under "Sources of inspiration" were studied for compositional shape only; no audio was sampled, no melody was quoted.

---

*Plan 9 salutes. We love you.*

## Related films

- [BUNNY STAGE 2](/2026/05/18/bunny-stage-2), the multi-planetary follow-up, two days later
- [LFG ORBIT](/2026/05/16/lfg-orbit), Plan 9 and OG Bobby drive a Tesla into orbit
- [BUNNY MANDALA](/2026/05/16/bunny-mandala), Sanskrit-mantra meditation in D major]]></content:encoded>
      <pubDate>Tue, 19 May 2026 02:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/18/for-those-who-rose/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/for-those-who-rose-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>Decan 6: Signal Discipline in a Noisy Week</title>
      <link>https://joshuaayson.com/2026/05/17/decan-06-signal-discipline-in-a-noisy-week/</link>
      <description>Alhena shows the hidden cost of noise: transmission quality, concise messaging, and recovery architecture matter more than raw effort.</description>
      <content:encoded><![CDATA[<!-- decan-crosslink -->
> **Part of [The Decan Log](/books/the-decan-log/index/)**: For the cosmology, astronomy, and journaling framework behind this decan, read the [Alhena chapter](/books/the-decan-log/alhena/). New to decanal journaling? Start with the [Introduction](/books/the-decan-log/introduction/).

## Opening

A noisy week does not test what you think. It tests what you transmit, and whether it reaches anyone in the shape you intended.

The cycle opened with a small provocation at home, the kind built to get a reaction. I gave it almost nothing. A light touch, no contempt, a short word about cleaning up what you set up, and then I went back to what I was doing. Not because the provocation deserved a strategy, but because the smallest accurate response was the whole correct one. Anything louder would have been noise I generated myself.

That was Alhena at work before I knew I would spend nine more days on the same lesson. The star asks a narrow, demanding question. Not what are you feeling, not what are you doing, but what are you sending, and is it the signal or the static.

The easiest answer of the cycle went to that provocation. The hardest one came later, and it did not arrive as a message at all. It arrived as silence.

If you are new here, a decan is a ten-day reflection cycle tracked through The Decan Log.

## The Star and the Signal

The photons entering your eyes when you look at Alhena tonight left that star in 1917.

At 109 light-years, this is the newest light of the first six decans. The year those photons departed carries its own signal. 1917 was the year a revolution remade the political architecture of half the world, the year the United States entered the first World War, the year of the first jazz recordings in New Orleans. Everywhere that year, old channels collapsed and new ones struggled to form. The noise-to-signal problem was global and acute.

Alhena is Gamma Geminorum, an A-type subgiant burning at roughly 9,260 Kelvin, about 123 times the Sun's luminosity and 2.8 times its mass. Spectral class A0 IV, which means it has exhausted the hydrogen in its core and expanded toward the giant phase. Not yet a giant, but no longer a pure main-sequence star. Midway between states, still transmitting at high frequency, still legible, but changing the channel.

The name comes from Arabic, al-han'ah, the brand mark, the identifying mark placed on a camel's neck. Alhena marks the foot of one of the Gemini twins, the point of contact between the constellation and the ground. Where the heel presses down. This is a signal star. The one that governs where transmission meets earth.

In this decan, that physical fact became the operating lesson. Strip away the signal architecture and everything transmitting in parallel turns into noise.

## What Is a Decan?

I track consciousness in ten-day cycles aligned with stars, adapted from the ancient Egyptian calendar. Thirty-six decans of ten days make 360, and five days outside time close the year. Each decan has a ruling star, a theme, and three phases: Initiate, Flow, Reflect.

Decan 6 belongs to Alhena and centers on transmission quality under noisy conditions.

### Initiate: Days 1-3 (May 9-11)

The first three days were about reading before reacting. The provocation at home, a quieter family stretch held warm and brief, and then a clean piece of bad news I went looking for on purpose.

The bad news was a test I sat for something I am working toward, and I failed it. Cleanly, with the gaps traceable to specific places I had not done the work. I did not flinch from the result and I did not build a story around it. I wrote down where it broke, queued those weak spots for drilling, and moved on. A failed test is a high-fidelity signal if you are willing to read it straight. The score was not useful. The map of where I was weak was.

### Flow: Days 4-7 (May 12-15)

The middle of the cycle ran hot. Work shipped on days the tank was already low, which is its own quiet proof that the systems hold even when the operator is tired. Throughput stayed up. The cost showed up in the body by evening.

The hardest transmission of the stretch was a short one. A pointed note arrived from the institutional side, making clear that something in my area had been handled without me. I read it. I sat with it. I answered in one clean line, no defense, taking the ownership it asked for and nothing else. The strength of the reply was in what it refused to carry. I am not going to argue with a posture. I am going to give exactly what was asked on the surface and let the longer record speak in its own time.

In the same stretch a quieter, better signal showed up. Someone I work alongside opened up about something they had been building on their own, and a real conversation got set to walk through it together. Genuine signal in the middle of the noise, easy to miss if you are only braced for the next hit.

The honest catch of the week was internal. Too many ideas, not enough runway between them. I caught myself cataloging instead of cutting through, and named it as the thing it was.

### Reflect: Days 8-10 (May 16-18)

The last stretch carried the unglamorous work. A long, monotonous slate of necessary maintenance, the kind that produces no external signal at all but holds the whole posture together if anyone ever looks closely. I worked straight through it. Then a low day where the right move was to honor a low number instead of overriding it. Staying put, hosting nothing, going nowhere. Reading the gauge and obeying it is part of the discipline now, not a failure of it.

Then the last day delivered the decan's whole thesis in compressed form.

I had spent personal time on high-trust, high-ownership work that protected something larger than me. The return, when the next stretch opened, was silence. No acknowledgment of any kind. And in the middle of that day an old reflex took the silence, which was only data, and folded it into a story about being unseen and unwanted. The drop was real. The numbness, the why bother.

What held was one move. I wrote the wound down instead of leaking it sideways. I put it in the log and did not let it touch a single decision or message. Then I waited for the whole day before drawing any conclusion from it.

The day rewarded the wait. By the afternoon, real collaboration arrived. People showed up, the work moved, no drama. The silence had been a slow channel, not a verdict. The morning's story was noise. The afternoon was the data. The discipline that told them apart was the simplest possible thing and the hardest to actually do under load. Log first, act second.

One conclusion did survive the full day, and it was strategic rather than wounded. Quietly absorbing unlimited cost transmits a signal of its own, that the cost will always be absorbed. That is the transmission I change going forward. Not as retaliation. As recalibration. Let the evidence accumulate, and let the record speak.

## Closing

Alhena was not a difficult cycle. It was a noisy one.

Difficulty would have been survivable on its own. Untreated noise was the actual risk. The discipline that worked was not effort. It was transmission. Say the small accurate thing. Log the wound before it leaks. Wait for the whole day before you believe the story. Then send only the signal.

## Decan Navigation

Previous: [Decan 5: Protection First, Then Renewal](/2026/05/08/decan-05-protection-first-then-renewal/).

Next: [Decan 7: Don't Confuse the Label with the Light](/2026/05/28/decan-07-dont-confuse-the-label-with-the-light/).]]></content:encoded>
      <pubDate>Sun, 17 May 2026 12:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/17/decan-06-signal-discipline-in-a-noisy-week/</guid>
      <category>journals</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/decan-06-alhena-journal-images/decan-06-alhena-journal-featured.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>LFG ORBIT: a doberman MC and a bunny philosopher drive a Tesla to Mars</title>
      <link>https://joshuaayson.com/2026/05/16/lfg-orbit/</link>
      <description>A 102 second napkinfilms music video. OG Bobby Johnson the doberman raps the engineering. Plan 9 the bunny raps the cosmos. A Tesla rolls onto a personal fiber platform, climbs out of the atmosphere, docks with an interplanetary shuttle, streaks past Saturn and Jupiter, and lands on Mars. Six iteration passes from a 90 second French house single to a 102 second bookended film with a Carl Sagan tribute outro and a soft Tagalog goodbye.</description>
      <content:encoded><![CDATA[# LFG ORBIT: a doberman MC and a bunny philosopher drive a Tesla to Mars

A Tesla idles in a near future garage. The door opens. A glowing cyan fiber platform sits outside. The driver rolls onto it, the platform launches vertically out of the atmosphere, docks with an interplanetary shuttle, and the shuttle accelerates across the inner solar system to a horizon line of Mars. In the cockpit are two characters. OG Bobby Johnson, a doberman MC, raps the engineering. Plan 9 Glenda Bunny, the copilot, plays two roles: reverent fan (paws up "LFG" salutes and a deep bow at "Mister Musk") and cosmic philosopher (five rap bars about counting old light and being people of the stars). The contrast IS the comedy and the heart.

[Watch LFG ORBIT on YouTube.](https://youtu.be/Bx1fu01mkRA) The film is Creative Commons (CC BY 4.0).

The brief was simple. Take a Touch Sensitive "Pizza Guy" flavored French house track, build it in ChipForge, and let two characters fight for the pocket in different vocal registers. OG Bobby on the gritty engineering. Plan 9 on the cosmic reverence. And bookend the film with a soft pond ambient intro and a production outro in honor of Carl Sagan. Six passes from a 90 second body to a 102 second bookended ship cut.

Six versions to ship. The audio engineering and the cinematic word overlays each took a couple of iterations, and the bookend framing had to be fixed once on v6 after the bottom letterbox clipped the bunny's legs in v5.

## 1. The song, F minor French house with a buzzing low arp

The score is a ChipForge composition at 120 BPM in F minor, 45 bars, two drops, one breakdown. Pizza Guy DNA: filtered funk bass, off beat Rhodes chord stabs on the and of every beat, four on the floor kick, open hat shimmer offbeat. Eight channels including kick_punchy, hat (tight plus open shimmer), clap_tight, bass_funk plus bass_sub, rhodes_warm stabs on Fm9 to Bbm7 voicings, supersaw_lead with pingpong delay, pad_warm_analog, and a mellow low buzzing arp_dark.

The arp is the v3 addition that turned the track from a music bed into a head bopper. It rotates i to iv to v to i voicings (Fm to Bbm to Cm to Fm) every four bars with sub octave emphasis on every bar one and bar three downbeat so it sits low and weighty. Rhythm pattern also rotates per section: head bop 8ths in Drop 1, triplet flavored in mid Ascent, full 16th buzz at the climax, sparse offbeat in the outro. Never the same two bars in a row.

Master chain is the standard ChipForge stack: parametric EQ, gentle multiband, transient shaper, sidechain kick to bass duck, glue compressor, stereo widener, limiter at minus 0.5 dB. Clean, no tape saturation, no noise floor.

## 2. The rap: a doberman MC and a bunny philosopher

OG Bobby Johnson handles the verses. Eighteen hard bars across three drops and a breakdown, plus one establishing line at 0:08. Every bar follows the spit rap rules: six to twelve words, hard consonant clusters (cracked, idles, stack, drilled, drove, magnetic, catapult, glass deck), a period or em pause every two to four beats, universal themes only (no real persons named beyond the brand affiliations).

The verses cover the engineering arc:

> Garage cracked. Tesla idles hot.
> Personal fiber. Private dock. Skip the lot.
> Stack the cars. Drive vertical. Crack the spot.
> Boring drilled deep. We drive off the plot.

And the stance line that frames OG Bobby's whole worldview, dropped at the climax bar of Verse 3 over a banner framed kinetic title card:

> I don't kiss the ring. I just clock the build.

Plan 9 the bunny gets two voice registers. Reverent fan chops (five total: "Thank you Elon" twice, "It is an honor", "LFG", "Mister Musk") and cosmic philosopher rap bars:

> Bunny in the void. Counting old light.
> People of the stars. Wake up tonight.
> Time is just distance. Slow on the wing.
> Galaxies hum the same wireless thing.
> We were always supposed to go.

Plan 9 gets the very last word of the song, then carries the Sagan tribute in the production outro. The contrast (OG Bobby respects the engineering but won't worship the man, Plan 9 is the believer) is what gives the film its emotional shape.

## 3. The voices, three personas on three buses

ElevenLabs handles all three voices, each with its own FX chain so they live in different formant bands and never fight each other in the mix.

OG Bobby on `og_bobby_johnson` (the official Napkin Films voice, husky, tongue in cheek gangsta rap, designed for spit rap with stability 0.35 and style 0.65 at speed 1.10). Processed through a broad bandpass plus presence boost at 3.5 kHz plus an aecho plate at 40 / 95 / 160 ms taps. Sits forward in the mix, clear and gritty.

Plan 9 reverent chops on `bunny_oracle` (wise, slow, lots of air, stability 0.62, speed 0.88). Processed through the talkbox vocoder bus: chorus then aphaser then narrow bandpass 600 to 2800 Hz. That formant filter is the French house vocoder color and it's what makes the chops sound like Plan 9's "machine bunny" voice instead of a regular TTS line. (The ffmpeg order matters: vibrato after aphaser silences the signal entirely in this build. Cost a full pass on i_want_to_be_martian v3 to learn that.)

Plan 9 cosmic rap bars on `og_glenda_bunny` (Plan 9's official rap voice, fast, machine cool, stability 0.30, speed 1.15). Same character, different effect treatment. Processed through a spacious multi tap delay bus: chorus plus broader bandpass (400 to 4500 Hz) plus aecho at 120 / 280 / 500 ms. The philosophical lines float; the chops stay glued. Same voice ID, different audio space.

All three buses get sidechain ducked under the music. Music duck windows cover OG Bobby's verse pockets at 0.78 multiplier, Plan 9 cosmic pockets at 0.82, the breakdown chops at 0.84. A song forward mix profile (music base 0 dB, voice negative 2 dB) keeps the music as the main event with voices riding on top.

## 4. The visuals: planet pageant, kinetic typography, ECU eyes

PIL stick figure animation at 854 by 480 at 12 fps, 1080 body frames plus 144 frames of bookend (36 intro, 108 outro). No subtitles. Any on screen text is cinematic typography that lands on bar boundaries.

The film has six narrative sections with distinct visual palettes. Garage (warm tungsten). Platform (fiber neon cyan and magenta deck with a pulsing tube extending up). Ascent (blue to black atmospheric gradient with aurora curtains and a sun rising from the Earth's limb with a lens flare streak). Dock (cold deep space, shuttle approaching with engine glow, docking umbilical extending). Interplanetary (deep space with five planets: Saturn with ring particles, Jupiter with bands and the great red spot, Neptune, blue planet, approaching Mars, plus an asteroid belt and a nebula bloom). Destination (Mars on the horizon with surface detail, Phobos overhead, shuttle silhouette descending with engine plume).

Three parallax star layers. Beat tight camera shake on every kick (subtle in Drop 1, harder in Drop 2). Four layer kick rings on drops. Chromatic aberration channel offset on heavy kicks. ECU close ups on Plan 9's eyes during the three reverent chops with gold halo backdrops, reframed in v6 so the head and ears stay in frame (the v5 ECUs at scale 110-150 with hip at H over 2 pushed ears above and feet below the frame edge).

Plan 9 also gets a cosmic glow halo (`glow=True` on `draw_plan9`) for every frame he's in a rap span. The visual cue says "this bunny is on his cosmic shit right now."

Kinetic typography moments, all on bar boundaries:

- Gold "LFG" smash card on the Drop 1 kick (chromatic shimmer with magenta and cyan ghosts behind the gold)
- Cyan edged cream "STAGE 2" smash card on the Drop 2 kick
- Glowing gold serif "MISTER MUSK." with "an ode to elon" subline over the reverent ECU bow at 1:12
- Banner framed angular "I DON'T KISS THE RING." over OG Bobby's stance bar at 1:14
- News ticker scrolling along the top during the opening
- Outro card "STAGE 2 · LFG ORBIT · NAPKIN FILMS · AN ODE TO ELON" at 1:30

## 5. The bookends: pond ambient and a Sagan tribute

Bookending the film is the convention from [bunny_in_the_cloud](/2026/05/08/bunny-in-the-cloud/) and the other recent Plan 9 films. A 3 second Napkin Films cold open at the front and a 9 second production outro at the back.

The intro is a "NAPKIN FILMS / organic arts llc / presents" wordmark over a mellow pond ambient bed. v5 used the stranger things cricket chirp but the user wanted something softer. v6 switched to `scripts/synth_pond_ambient.py` output: clean sine plus FM warble crickets layered with bass frog ribbits at irregular intervals (every 1.2 to 2.5 seconds). No bit crush, no tape saturation. Mellower and cleaner.

The outro is a 9 second cosmic tribute to Carl Sagan. Plan 9 silhouette small against a deep starfield with a soft gold nebula bloom. A single pale blue dot Earth in the corner with its label. Three reverent lines paraphrased by Plan 9 in Sagan's voice (slow, lots of air, on `bunny_oracle`):

> We are star stuff.
> The bunny carries that light.
> Goodnight from the void.

Then a soft Tagalog goodbye: "Paalam." (a new foreign language for the Napkin Films catalog and a small personal note to Joshua's Filipino heritage). Cricket ambient callback under the final fade, bookending the bookend. Dedication card "IN HONOR OF DR. CARL SAGAN, 1934 TO 1996" holds throughout.

Carl Sagan was a wise human. The cosmos is bigger for having had him.

## 6. The pipeline: six passes, five layer mix, archive every version

The pipeline is the standard Napkin Films chain. Render scene frames in PIL. Build voice stems via ElevenLabs in three separate buses (each cached on a slug hash of the text plus persona plus emotion plus intensity, so re runs cost nothing). Synthesize SFX via numpy (no samples). Render the ChipForge score via the sibling repo. Final mix with ffmpeg in a five layer amix (music plus rap plus chops plus cosmic rap plus sfx) with sidechain duck windows and a song forward profile.

Every version archives to `output/films/lfg_orbit/v<N>.mp4` so v1 through v6 all coexist for A/B comparison. Stems hardlink into `output/working/lfg_orbit/v<N>/` for re editing. Verification runs after every mix: audio integrity, duration check, per beat audibility against the manifest, fade out timing. v6 passed 38 of 38 audible beats.

The pre render gate (`scripts/timing_check.py`) catches voice beat overlap and slide before the render kicks off so we don't waste five minutes rendering 1080 frames to discover the last beat got clipped by the fade. (Lesson from earlier films.) Future v7 will likely fold in a `/verify-render` skill that runs the full QC pass automatically, surfaced from the recurring friction analysis.

Cross links to other Napkin Films Plan 9 productions:

- [THE INTRUDER](/2026/05/09/the-intruder/) (Plan 9 in the AWS Availability Zone)
- [THROUGH ME](/2026/04/25/through-me/) (Plan 9 channels Watts)
- [PLAN 9: EMERGE](/2026/04/30/plan9-emerge/) (the cyborg origin)
- [BUNNY IN THE CLOUD](/2026/05/08/bunny-in-the-cloud/) (Plan 9 finds the data center)
- [I WANT TO BE MARTIAN](/2026/04/18/i-want-to-be-martian/) (the earlier Mars film)

## License

This film is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link CC BY 4.0. ElevenLabs voice audio is licensed content and is not redistributed in source form. "Tesla," "SpaceX," "Starship," and "The Boring Company" appear under nominative fair use as cultural reference for commentary and tribute.

Plan 9 carries the light.]]></content:encoded>
      <pubDate>Sun, 17 May 2026 01:00:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/16/lfg-orbit/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/lfg-orbit-hero.webp" type="image/jpeg"/>
    </item>
    <item>
      <title>BUNNY MANDALA: a six-voice canon of Aum mani padme hum sits over Satie and Pachelbel, while Plan 9 raps a Sanskrit space poem</title>
      <link>https://joshuaayson.com/2026/05/16/bunny-mandala/</link>
      <description>A 3:29 Plan 9 meditation. Satie&apos;s Gymnopedie No. 1 and Pachelbel&apos;s Canon in D fused into peaceful trance, while a six-voice canon chants the sacred Tibetan mantra Aum mani padme hum, entering one by one like Row Row Row Your Boat until all six lock in unison. Plan 9 raps an original Sanskrit space poem over the top. Geometric lotus mandala in eight chakra palettes, lattice of tiny bunnies orbiting the center, the Plan 9 bunny holding the breakdown with eye contact and a periodic blink. Five-limit just intonation in D so every pure 3:2 fifth and 5:4 third locks against the drone. Nine ChipForge channels, six ElevenLabs voices plus OpenAI Coral, all autotuned to a D-major mantra melody, cathedral-reverb mixed. CC BY 4.0.</description>
      <content:encoded><![CDATA[# BUNNY MANDALA: a six-voice canon of Aum mani padme hum sits over Satie and Pachelbel, while Plan 9 raps a Sanskrit space poem

[Watch on YouTube](https://youtu.be/-VyVIHWDgbo). A 3:29 Plan 9 meditation. Satie's Gymnopedie No. 1 (1888) and Pachelbel's Canon in D (~1680) fuse into peaceful trance, a six-voice canon chants Aum mani padme hum on top, and Plan 9 raps an original Sanskrit space poem above that. The mandala breathes, rotates, and slowly evolves around the still center. The bunny holds the breakdown. Eyes meet yours.

This one is licensed [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## The premise

Two public-domain compositions, both in D major, share a harmonic skeleton: Satie's stepwise modal melody from the Gymnopedie sits perfectly on top of Pachelbel's repeating ground bass (D, A, Bm, F#m, G, D, G, A). The film fuses them at 110 BPM as the foundation of a slow trance, then layers a sacred chant on top. The chant is the heart of the piece. The film closes with a soft Sanskrit goodnight. Shubh raatri, namaste.

## The sacred mantra

Six voices, each cached and autotuned, enter one by one in canon style, like Row Row Row Your Boat, starting at bar 5 (about 11 seconds in, while the music is still mostly the Surreal Bowl drone). A new voice joins every four bars (8.7 seconds). All six are stacked in unison by about 55 seconds in, and they chant together through the Pachelbel ground, the Riser, both drops, the breakdown, and the Return.

```
voice 1  bar 5    og_glenda_bunny     Plan 9 lead
voice 2  bar 9    bunny_oracle        Plan 9 sage
voice 3  bar 13   narrator_warm       Bella
voice 4  bar 17   child_curious       Gigi
voice 5  bar 21   elder_wise          Adam
voice 6  bar 25   performer_coral     OpenAI Coral
```

Each voice says "Aum, Mah-nee, Pud-may, Hoom" with the same phonetic transliteration, tuned for English-trained TTS so the Sanskrit reads authentic. Then autotune_voice.py pitch-locks each clip to the same four-note D-major mantra melody:

```
Aum    D3   root, deep opening
Mah-ni A3   perfect fifth
Pad-me F#3  major third
Hoom   D3   root, resolve
```

D3 (146 Hz) is chest register. The first pass was at D5 (587 Hz) and sounded like chipmunks. Dropping two octaves put the voices in their natural ranges, so the autotune barely shifts the source. Real chanting register, the way Tibetan monks actually sing.

The mix has a multi-tap cathedral reverb (60/150/320/640 ms taps with damped feedback), a long fade-in per voice (six seconds of bloom), light stereo spread across the six voices, and a master volume swell that rises from 0.35 at first entry to 1.0 once all six are stacked.

## Plan 9 raps a Sanskrit space poem

Above the canon, Plan 9 narrates an original Sanskrit space poem in mantra-rap cadence. The same og_glenda_bunny voice that says "Shubh raatri, namaste" at the very end is on this layer too, speaking clearly without autotune, the natural Plan 9 voice. Two full passes through the song so the refrain hook lands across both halves.

The refrain is the mantra itself:

> Aum, Aum, Aum mani padme hum.

Verses between the hook evoke cosmic emptiness:

> Akasha yaatri, kosha-traya yaatri.
> Sthoolam, sookshmam, kaaranam.
> Nakshatra mandala, chandra deva.
> Anantam vyoma, anantam shoonyam.

Vocabulary key: *akasha* (boundless ether), *gaganam* (firmament), *yaatri* (traveler), *kosha-traya* (the three sheaths of being, gross / subtle / causal), *nakshatra mandala* (the constellation circle), *chandra deva* (moon-god), *anantam vyoma* (infinite sky), *shoonyataa-sindhu* (ocean of emptiness), *kamala chetana* (lotus-consciousness), *brahma sootram* (the cosmic thread), *antara jyotih* (inner light), *taara-loka* (the star-world), *adi madhya anta* (beginning, middle, end). Plan 9 is the *vyom yaatri*, the sky-traveler.

The Plan 9 voice is processed with a cosmic-cathedral chain: highpass at 90 Hz, lowpass at 5500 Hz, a 2:1 compressor with +2 dB makeup, four-tap aecho (120/320/680/1400 ms taps from short room to long hall), a subtle aphaser for stereo bloom, and a 25 ms Haas delay on the right channel for cosmic stereo width.

## Nine ChipForge channels

Through-composed in D major, BPM 110 constant, 96 bars across 8 patterns. Voices assigned through the ADR-026 behavioral grammar (intent before instrument):

| Channel | Role |
|---------|------|
| KICK | kick_deep four-on-floor with sidechain trigger |
| SNARE | noise_clap backbeat with riser fills |
| HAT | hat_crisp 8th-notes with wobble panning |
| BASS | sine_bass on the Pachelbel ground, glide between roots |
| DRONE | organ_warm pedal D2, fermata, long-tail reverb (CathedralDecay) |
| LEAD | custom mandala_lead carries the Gymnopedie with 16th-note elaboration, sustain 0.85, release 1.30, glide 40ms (HeroLead) |
| PAD | custom mandala_pad with slow LFO filter breathing, chord stabs on beats 1 and 3 in the drops, vocal_ah doubling (CelestialPulse) |
| ARP | pluck_mellow arpeggio pivoting toward the lead's anchor notes |
| BELL | fm_bell tolls D4 every 2 bars with damped reverb |

## Pure intonation, hard-won

The v3 score used Pythagorean tuning on the atmospheric sections, intended for purer 3:2 fifths. The problem: Pythagorean major thirds (F# = 81/64, 408 cents) clashed with the natural 10th harmonic of the sustained D2 drone (just M3 = 5/4, 386 cents). The two F#s landed about 21 cents apart and beat at 9 Hz. The result was an audible warble starting at :42, peaking at :47, and continuing whenever the lead touched F# over the drone. The v4 pass reverted to 5-limit just intonation across every section. F# now sits at 733 Hz, exactly the natural 10th harmonic of the drone. Beat-free.

The v5 pass found one more wobble source: the supersaw detune layers on the mandala_lead (plus or minus 7 cents) and mandala_pad (minus 10 cents) were producing slow 2 to 5 Hz beats between layers on sustained notes. Zeroed both. The piece is clean because clean is the aesthetic.

## Visual stack

Python plus PIL polar geometry, 854x480 at 12 fps, 2512 frames. Six concentric rings turn at different rates: outer lotus petals (1.0x scale), mid teardrops counter-rotating, triangle flares, an inner dot ring, plus two rings of tiny Plan 9 bunny silhouettes orbiting like a mandala lattice of bunnies. The bunny rings replace the v3 star gems. Eight chakra-inspired palettes (indigo silver, emerald gold, turquoise magenta, violet electric, full rainbow, warm pink, silver white, indigo fade) crossfade at section boundaries.

Sparkle particles emanate continuously from the center; about 22% of them are tiny bunny heads sparkling outward instead of dots. In the breakdown, the Plan 9 bunny rises to full alpha at the center with the contemplative expression, `look_preset="center"` for eye contact, micro pupil drift for living gaze, and a periodic blink every 4.5 seconds.

## The bookend

The film ships with a 4-second NAPKIN FILMS intro card scored with an ascending D-major sine-bell arpeggio (D5 to F#5 to A5 to D6), much softer than the cricket synth used in earlier productions. The 7-second outro card layers a descending D-major bell tail under Plan 9 saying "Shubh raatri. Namaste." in soft Sanskrit. The Devanagari script appears on the card alongside the transliteration.

## Production passes

```
v1   first cut, original Pythagorean tuning
v2   visual iteration
v3   showcase, but audible Pythagorean dissonance against the drone
v4   tuning fix 1: pythagorean -> just intonation
v5   tuning fix 2: zero supersaw detune on lead and pad
     visual: tiny bunny lattice rings + particle bunnies + bunny blink
     bookend: D-major bell intro + Sanskrit "Shubh raatri" outro
v6   added six-voice canon of Aum mani padme hum (D5, too high)
v7   dropped the canon to D3 chest register, slow build from bar 5
v8   added autotuned Plan 9 mantra narration loop layer
v9   added Plan 9 clear-voice Sanskrit space poem in mantra-rap cadence
     SHIP
```

## Stack

Python 3.13. PIL. [ffmpeg](https://ffmpeg.org). ChipForge for the music with 168 instrument presets and the FilterEnvelope multi-layer synthesis. [ElevenLabs](https://elevenlabs.io) and OpenAI for the voices. [rubberband](https://breakfastquay.com/rubberband/) for the autotune. Per-pass versioned archive convention at `output/films/<scene>/v<N>.mp4`, never overwrite.

## License

Film: **CC BY 4.0**. Remix it, repost it, drop it into your own thing. Credit "Napkin Films / Organic Arts LLC" and link [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

Source compositions: "Gymnopedie No. 1" by Erik Satie (1888) and "Canon in D" by Johann Pachelbel (~1680). Both works are in the public domain. The ChipForge arrangement is original and licensed CC BY 4.0.

ElevenLabs voice audio is licensed content and is not redistributed in source form.

## Related films

- [Cantus Rave](/2026/05/02/cantus-rave): Pärt's canon transformed into festival DnB, same demoscene-cracktro lineage.
- [Bunny in the Cloud](/2026/05/08/bunny-in-the-cloud): Plan 9 voyages through a galactic Factorio cloud.
- [Bunny Run](/2026/05/12/bunny-run): Plan 9 the cyborg bunny runs from his own mortality.

Aum mani padme hum.]]></content:encoded>
      <pubDate>Sun, 17 May 2026 00:30:00 GMT</pubDate>
      <guid isPermaLink="true">https://joshuaayson.com/2026/05/16/bunny-mandala/</guid>
      <category>projects</category>
      <dc:creator>Joshua Ayson</dc:creator>
      <media:content url="https://joshuaayson.com/images/projects/2026/05/bunny-mandala-hero.webp" type="image/jpeg"/>
    </item>
  </channel>
</rss>