fifthrevision

Why I built dtg

Wed, 28 Oct 2026 03:59:00 GMT

I don’t remember when, but it got to a point where the colors I picked for the design systems became preposterously difficult to maintain. Perhaps it started around the time when I started building them by meticulously layering semi-opaque rectangles in a drawing tool like Figma.

There’s an art and a science to building pleasing color systems. To achieve the desired uniformity I wanted, I found it easiest to build the scales algorithmically, that is, defining all the constituent parts and then deriving each step from them. The colors, whether sampled from Figma or a dedicated tool that I built, then get put into the variables panel in Figma. This process works for as long as there are no changes to them, at which point it becomes deliriously difficult to maintain.

I remember two specific instances that led me down the path to dtg. In the first, I created this elaborate system of rectangles of different opacity in Figma and sampled every single swatch into the variables panel. Once, I decided that the background color needed to go darker. I had to go back into the project, change the color of the background frame, and then manually update all 54 colors inside the design system. This was but one of many.

I used to maintain elaborate structures of rectangles so I can tweak colors and re-sample them.

The dedicated web tool simplified the first half of that process. The color palettes could now be computed, but every tweak still meant updating significant swaths of the palette by hand. And changes are inevitable. After all, colors are contextual to how they are used; it is nigh impossible to get it right the first time round.

I remember vividly the moment I took a detour from an active project to finish the first version of dtg. I was trying to visualize a half a percent (!) shift among a set of background colors and I was deliberating the line where a separation becomes a distinction. Because the colors were built in a scale, shifting one meant that every other color after it had to follow, and this triggered a cascade of alt-tabs and copy pastes. Every deliberation turned into an arduous choreography.

The first version of dtg cut each iteration down to the time required to change a value and save a file. Subsequently, I found myself with an interesting visual problem. I’d been staring at a well-balanced dark-mode palette and something felt a bit off. After several weeks of staring, I realized that the whole palette was a tad too green. I could’ve edited the definition file by hand, but picking the new color required some finesse. With a slight detour into versions 0.3 and 0.4, I could now fire up the editor, open the color picker, make changes and see Mosaic (my design system) hot reload immediately. I found that the sweet spot is in reducing the RGB green channel from 28 to 25.

That’s why I built dtg. Storing the recipes rather than just the color values lets me tweak them and immediately see the results. It makes a laborious process simple. And because the basics are now simple, it allows for much more discretion and sophistication in how color systems can be built.

I’ve now connected the editor to Mosaic’s public colors page, so you can try that part yourself. Open the hues palette, click the theme swatch, change its hue, and then look at the Button page. You’re editing the colors of a working design system, with components there to judge the result.

I think of it as a variables panel for colors in software projects. It’s open source; the code is here if you want to see how it works.

dtg 0.4

Mon, 26 Oct 2026 17:48:00 GMT

This release has three main changes:

A much improved onboarding experience. Better readme, more sensible vocabulary, and dtg init writes a working definition with the option to start with the Material or Tailwind examples.
UI and UX improvements to the editor. Yes, it’s just called the editor now (invoked with dtg edit). Particular attention was paid to how the color picker behaves and functions.
An important under-the-hood change: colors are now stored as unbounded OKLab values and each algorithm decides which math space to compute in. Previously, dtg guessed a color space from how the inputs were written and converted everything to it before computing. That could clip wide-gamut colors, and colors written in different notation could produce different results. Gamut now only matters on output.

dtg 0.3

Mon, 19 Oct 2026 18:16:00 GMT

Version 0.3 of dtg is out. Check it out on GitHub!

This is a substantial release. By the end of 0.2, I knew that the next version would entail major changes. I didn’t appreciate their extent until the work was underway:

A new top-level palette keyword in the definition file. Palettes collect colors into a set for viewing and manipulating. They are for an earlier, more exploratory stage of color work, where designers puts colors side by side and adjust them until they work well together. Palettes also serve as inputs to roles and systems, and replace the use of constants today.
System addressing now uses method parameters instead of paths. Use sky(3 tint) instead of sky/3/tint. Dot notation is still used for traversal, e.g., warm-wash.red(6). This syntax makes it easier to distinguish what’s being used from what’s being configured, while more closely resembling CSS color functions.
A simpler set of out-of-the-box algorithms. ink-ramp became tint, oklch-scale became scale and blend was removed by a group of tint systems. The algorithms are also more focused, with simpler interfaces and fewer responsibilities. Definitions are more concise, and output is now explicitly controlled by the definition file rather than the algorithms.
Modes support color-scheme and inheritance. Modes can now be associated with light or dark color schemes, and they can inherit from other declared modes as well. This makes it easier to build related themes, including high-contrast variants or themes that differ by only a handful of colors.
Edit the definition file through the bundled web editor. As much as I like the syntax, color work is fundamentally visual. In 0.2, the web editor let you preview colors and how they are used. In 0.3, it supports editing and saving directly. I’ve paid particular attention to the color picker, making it easy to adjust colors, especially when working with dtg dev --build. A few things are still missing before it is possible to author a definition file from scratch, but we’re getting there.
Quality of life updates to the web editor. Systems can now be simulated without requiring a reference. Color scales are displayed more clearly, and hovering over any swatch reveals its color information.
And tons of changes to smooth out the rough edges while using dtg:
- The config file dtg.yaml is renamed to dtg.config.yaml so that it’s both more differentiated from the definition file, and closer to other config files inside a codebase.
- There is no longer a default path for definition files. Specify them in the config file.
- dtg emit becomes dtg build and the --live flag got renamed to --watch to align the verbs to other tools.

The CLI can also generate static pages for publishing (dtg docs --out <dir>). Here are the colors that fifthrevision uses, along with a preview of Mosaic’s (my design system) colors and component library.

Truthfully, we’re still in the early stages of the project, where many of the building blocks are still being reconsidered and refined. Version 0.2 demonstrated the value of a color tool that captures how colors are derived. Version 0.3 focused on making the idea practical, with a coherent foundation and usable interface. The basic shape should now be largely stable, with fewer breaking changes going forward. The focus for the next release will be on from-scratch authoring and extension points, as well as support for gradients.

This tool has been invaluable to me and my coding agents as we iterate on Mosaic, and hopefully it will be for you as well.

Axle release 0.33 and 0.34

Mon, 12 Oct 2026 05:11:00 GMT

I should make a habit of writing about releases when they come out. The weekly cadence means announcements sometimes get bunched up.

0.33 and 0.34 are substantive Axle and CLI releases that let me acheive a personal milestone: I have a agent doing financial research on a schedule and sending me a text message with recommendations.

On the CLI side, 0.33 added scheduling to Axle CLI on macOS via launchd. Tasks can now run on interval or schedule through the axle schedule subcommand, and can be retrieved using session and resumed as other Axle sessions. To make this useful, every CLI recipe gets a tool set unless specified.

0.34 completes the scenario above by adding Skills. CLI now supports the Agent Skills spec. Drop a skill in your local .axle/skills or .agent/skills folder and Axle will pick it up. Then, there are a lot of other changes under the hood to make sure the shape and ergonomics are right.

On Axle core itself, 0.33.0 and 0.34.0 bring in a grab bag of improvements. Skill support as a first class Agent concept. Pending Turns show up on Transcript, making it simple to render queued messages. New lifecycle hooks (async onSettled and onIdle) on the Agent object enable better lifecycle interactions. The static model registry got replaced with a dynamic one backed by models.dev so that consumers can look up real-time model info and pricing. There are tons of work under the hood as well: stability, robustness, protocol improvements, as well as a few breaking changes coming from implementing better mental models. Building a library is a process of understanding the problem, and then understanding the problem over and over again*.

And oh, TypeSafe’s decision API is in Core as experimental. I’m looking forward to integrating it as a first-class citizen for classification into Agent – more on that soon.

Full release notes can be found here.

Goodbye Jekyll, hello Astro

Tue, 06 Oct 2026 07:00:00 GMT

The first commit of this version of the website happened in February 2017 (169e91e7). It went from a set of handcrafted HTML and CSS files (edit: I was wrong, it was a Wordpress site!) to a site statically generated with Jekyll.

Jekyll gave me the vocabulary and the confidence to do bigger things. The loose collection of pages turned into a coherent set of essays and portfolio entries. Then, a reading list and reviews I would write of them (that ended up being a tough thing to keep up on). Later, a microblog.

In the last few years, I’ve noticed creakiness in the Jekyll ecosystem. Once, I upgraded the Ruby version and the build broke. Plugins stopped getting maintained (I’m looking at you, jekyll-paginate-v2). Liquid 4.x is limited in what it can express (5.x looks like it’ll never get supported). Lastly, I’m not a Ruby person and I don’t want to maintain custom extensions.

Recently, I’ve used Astro for a few content-heavy static sites and I liked what I saw. Well, first and foremost, I’m a TypeScript person. My requirements for this site remain the same: static-site generation primary, JavaScript as an enhancement layer, and building on top of a variety of content types. Back then, I flirted with the idea of porting the site to Astro, but the idea of undoing years of technical debt felt daunting so I never took the next step.

Yesterday, I bit the bullet and ran the migration using Claude Code. It was done in a few hours with Fable 5.1 driving Opus 5.5 subagents and the entire process went as smoothly as one can hope. Layouts went from Liquid to Astro components. The content folders became more sane; it’s interesting how many Jekyll conventions can quickly become limitations once the use cases outgrow what they were designed for. I took the opportunity to convert SCSS to plain old CSS — CSS is mostly at parity these days with a few features in the pipe. The codebase reads better, runs better (no more fumbling with bundler, why no run scripts?), and the generated output is basically byte-identical.

Then, I shipped my first site change in years, a revamped projects list. Which is to say, fifthrevision is now officially on Astro. So far so good! I’m sure I’ve traded one set of constraints for another. Time will tell.

For nearly a decade, you served me well. Thank you, Jekyll.

Anti-social social technology

Wed, 30 Sep 2026 07:00:00 GMT

The first question we ask of a new technology is what can this product do for me. It’s a useful lens for evaluation, and AI is right in the middle of answering that: do my work, read my emails, write my docs, achieve my dreams, yada yada.

The question seldom asked is what can this product do for the other. How do we make it easier for the other person to understand us? How do we take the burden off other people that we work with? How do we help other people? Much of what we use today don’t arrive at this stage of questioning.

AI is poised to be the most transformative technology in my lifetime. It is also, so far, a Randian ideal: it accentuates differences and reinforces individual preferences. However, we are social creatures who rise and fall together. So the imperative question we should all be asking at the moment, designer or not, is what can this technology do for us.

This week: Axle 0.31, 0.32

Tue, 15 Sep 2026 07:00:00 GMT

I haven’t posted an update in a while because I took a vacation and had to work for money! That said, Axle shipped a few minor versions:

Axle 0.31.0 shipped a major CLI revamp. This update took everything I’ve learned building apps with Axle and put it into a modern, usable TUI. In addition to the new UI, Axle CLI now supports follow up interactions and resumable sessions, as well as more sensible configuration and setup.
Axle 0.32.0 reworked the thinking Turn and stream objects. It’s a minor but breaking change to the format. The implementation of thinking has always been a little janky, and the recent release of Muse Spark 1.3 gave me a chance to revisit it so that it’s a little cleaner.

I’m personally pretty pleased with the CLI updates. This resolved a few longstanding issues I had with the previous implementation, including the fact that it was just really ugly. With the open weight models being quite cheap and good these days – I’m really liking GLM 5.3 Flash – I’m harboring a few automation fantasies on my life. Not quite there yet, a few more gaps to close, but I’m hoping to have some updates soon.

Store colors as algorithms not hexes

Sun, 13 Sep 2026 07:00:00 GMT

I’ve been thinking a lot about colors recently. It is one of the first things I do when starting a new design project, and one of the things that goes through iterations as the project progresses. Colors express much that is difficult to quantify: information, fashion, mood, and many other intangible qualities that make software feel comfortable or hostile. Color systems can be difficult to work with; the reasoning behind the systems is often opaque, and they are deeply embedded in apps and tools. I’ve been working on a tool for myself called dtg (Design Token Generator), which I hope will lessen the work of iterating on colors, and increase the satisfaction of doing so.

How I generate colors

I used to start projects by generating a palette at coolors.co and turning it into color scales via an online Tailwind color scale generator. I first saw this with Google’s Material Design, and Tailwind was where I had the most first-hand experience. It was a step up from picking arbitrary colors, but I found the gradations limiting. It felt like painting with a limited set of crayons.

Over the years, my process gained a few new tricks: I started creating different color scales for different uses, breaking away from the 50-950 steps; I started blending colors in different proportions within a single scale; and I started computing colors in OKLCH so a move in lightness reads the same whether the hue is yellow or blue. One of the benefits of varying color scales based on semantic meaning is that we can use colors to build structure instead of relying solely on signposts. We have a natural acuity for visualizing surfaces and depth, and color systems should take full advantage of that.

Sunnyday has a particularly dense UI which benefits from tweaking the nuances of how surfaces layer upon each other. I want to say I did a good job.

The challenge with this approach is that the work is no longer simple. And this leads to two broad problem areas:

First, color systems are rarely one-and-done. We often need to make adjustments to accommodate new uses or change how the product feels. Because there are different algorithms for each scale, and they are all anchored on different colors, and they are often blended on a graphics tool, tweaking one requires going through the entire motion to generate the new hexes. Furthermore, documentation is often an afterthought, and the method for generating the color is stuck in a Figma file from years ago or no longer preserved.

Second, keeping colors in sync between the various tools that I use is a frustratingly menial job. As an illustration, if I need to add a new in-between color, I need to go into Figma to add the color, make any name changes, ensure that one-off colors are updated properly, and then do the same in every software project where the colors are used. The complexity increases exponentially with the sophistication of color generation, and over time I get bogged down in the minutiae.

These little speed bumps make band-aid fixes so much more tempting. New colors get added arbitrarily: why not just pick an arbitrary one and go? Tokens drift because it’s easier to just eyeball it in the codebase. Swapping color references to avoid rejigging the scale. The system that was once coherent turns discordant.

Keeper of yellows

I had a thought the other day: what if the methodology for generating colors could be recorded and reproduced. What if adding a new color would then be as easy as pointing to another point on that continuum. And lastly, what if all changes synced and perpetuated across all usages effortlessly.

These gave rise to the utility dtg. dtg is a tool that lets designers express color systems in algorithms, describe how they generate into variables, and sync those variables across the tools and codebases that use them.

Let’s dive into an example. These days, I’m obsessed with color scales that start at a certain color but tint shift into a new tone as they move along a brightness scale. In Sunnyday’s light mode, I have a very light blue surface that gets cooler as it darkens. Inside of dtg, I declare a tint algorithm named sky with a base of #fcabda and a tint of #012012. I then have a set of semantic variable names that point to various points on the scale, such as sky(15), where the selector (the 15) means 15% tint over that base. The token name is the recipe.

Here’s a snippet from the configuration file:

dtg: 1

modes: [light]

systems:
  sky: # a cool tint over a warm base
    algorithm: tint
    params: { base: "#fcabda", tint: "#012012" }

core:
  surface:
    canvas: [sky(0)] # the base, with no tint over it
    card: [sky(15)] # 15% tint over the base
    floating: [sky(22)]

In the past, I would calculate the colors once, often by creating overlapping squares in Figma, setting the opacity, picking them with the eyedropper, and then setting them into variables. Now, I declare them in a configuration file, generate the CSS file, and check it into the codebase.

The beauty of this system is that if I decide that card needs to be slightly darker, I can nudge it towards sky(16) or sky(18) — or sky(15.5), since the selector is a coordinate on a continuous ramp rather than a position in a list. In fact, I can nudge the entire scale by 1 or 2 points or switch up the base or tint color and maintain the brightness steps. This operation is as easy as setting one number or color in the UI and looking at the updated result. Gone are the days when I had to scavenge for where the original worksheet lived, update all of them, copy everything over, and do it all over again until I got to what I want. The iteration cycle is night and day.

An upside of this approach is that since the color scale is now defined in a continuous spectrum, we can have infinite mappings and different step sizes between the different variables. In Sunnyday alone, I have more than 15 uses of the sky tint with step sizes ranging from 0.5% to 15% between them. This lets me really fine-tune the relationships between adjacent surfaces, as opposed to leaving them to the mercy of a discrete, fixed-step scale.

Last but not least, because colors are directly materialized into their use sites, it becomes simpler to keep them in sync between all the different tools. As an example, in the past when I had to rejigger a color scale it was a nightmare, because I had to first update the primitives, find every other variable that pointed to it and make sure they were still right, and then do the same in the codebase. Mapping this in dtg generates a more comprehensive list, but because the mappings are semantic, AI can compare the list against all the surfaces and confirm it’s up to date.

I have converted this website and Sunnyday to dtg and can confirm that it works really well. For Sunnyday, it cut the iteration time I described above from days to minutes. For fifthrevision, every theme went from a set of arbitrary, unmanaged colors into a single set generated by a fixed algorithm, which is much easier to maintain. It also means I no longer have to go hunting for the arcane Figma file where it all originated every time I want to make a change.

Bells and whistles

Other features in dtg cover additional things you might want your color system to do. There are ways to generate directly addressable color scales like blue 50-950. The scale algorithm blends out from a base in OKLCH toward a light and a dark target, and like the tint, its selector is a coordinate on a continuous curve, so a palette in steps of 50 or an uneven ramp is just a different list of points.

Another cool feature that falls out of algorithmic generation is the ability to twin opaque and transparent colors. sky(15) on the tint algorithm materializes a color that has 15% of the tint composited over the base; sky(15 tint) generates the tint as a 15% alpha only. This is especially useful for separators and hovers that may have to sit over unknown surfaces. Finally, there is support for overrides and color pinning. These values sit in the definition next to the system they bend, and they survive regeneration.

The rest of dtg is quality-of-life stuff. dtg build can write any supported variable format, including CSS, SCSS, Tailwind v4, and DTCG. Then there’s a web server, dtg dev, that renders a web app where palettes are displayed in their full glory: the OKLAB delta E between adjacent steps, which roles demanded each step, side-by-side comparisons, color modes, etc. I’m especially excited for this since it really takes color work to the next level. Designers should be able to go in and use all the tools at their disposal to tweak the colors to their heart’s content. As of 0.3.0, edits made there write back to the definition, so the entire lifecycle is complete.

I have a few ideas for immediate next steps: supporting per-project custom algorithms, gradients and more complex color definitions. I’ve also considered non-color tokens like font ramps and corner radii, but I’m going to focus on making the color experience first-rate before covering the rest of the design system.

That’s where 0.2.0 is at the moment. The project is open source and freely available on GitHub. Please use it, tell me what you want dtg to do, and go out and make some kick-ass design systems.

Updated Oct 16 to reflect the reworked syntax. Release 0.3.0 refined both the file structure and addressing mechanism with plenty of new features for building and editing!

Intelligence and behavior

Wed, 26 Aug 2026 07:00:00 GMT

There has been constant fighting with the latest crop of AI models.

A few things I’ve noticed: AI models are much more eager to jump in and do instead of understand what you want. When they write, the output is jargon-filled and convoluted. Worst of all, the recent Opus 5 just flat out make things up; over the last few weeks, I’ve had multiple incidents where after I push on a specific point in a plan, the model tells me that it made a mistake and acquiesces.

While none of this is indicative of intelligence per se, these behaviors make the model unpleasant to use. It feels as if they don’t understand my goals, try to paper over subpar decisions, and the most egregious of all, lie. I know I’m using people words here, ascribing intentionality to floating point numbers computed across arrays of special-purpose silicon. However, language is inherently anthropomorphizing; it is what we use to express and communicate with each other, and now with computers.

The thing is, none of this is inherent to the mathematical properties that create artificial intelligence. This is all trained behavior. My guess is that the pursuit of AI models that perform well on benchmarks and long-horizon tasks that leads to choosing verifiable rewards over human feedback creates behaviors that look like this. Inattentive and dismissive.

I’ve long thought that intelligence is not a linear measure. I had a conversation recently with a friend about this where I argued that preferences–for example in language and art–are not something that can be captured by scaling laws. He disagrees. I was arguing that there are different dimensions to intelligence and maxxximizing one will diminish others. A better way to frame it would be to separate what it can do versus how it behaves.

Perhaps soon, people will start talking about IQ vs EQ again. Perhaps one day AI model makers will find the right balance between the know-it-all and the we-get-you. But I’m not holding my breath.

This week: dtg and company

Sun, 23 Aug 2026 07:00:00 GMT

I spent a good part of this week working on a color system to token tool called dtg. It’s a somewhat niche tool that solves a long standing problem that I have. I’ll have more to say about it shortly, but suffice to say, I’m real stoked about it.

Axle got a 0.30.2 bump. Bug fix and a refinement to the prompt compactor API. It feels pretty good now. I’ve been test driving axle-code on the new stealth model on open router, ox alpha, and I’m overall really happy with how rock solid Axle is. Occasionally, I wished that I can compile typescript down to binary (yes I know about scriptc) just to really get access to real multithreading, but as it stands everything is fast enough.

Speaking of ox alpha, rumor has that it’s a GLM or GLM-based fine tune. It definitely has some Claude-isms in the text it emits (and less so GPT-isms). After running it for a bit, I’ll pin it at around a below Sonnet, above Haiku level of intelligence. In my subjective measure, coding ability is be inversely proportional to the amount of frustration I feel while using it. This new model often runs itself into a quagmire and needs me or a better model to bail it out; this is the first time I’ve had to revert my git history while using an AI agent.

I’m making little progress on the eval work that I’ve been mulling on. The approach that I’m taking — a test harness vocabulary built on knobs on LLM as a judge – feels like a dead end. It all still feels like syntactic sugar and not a meaningful step forward. Part of it is that it’s really hard to know what correct means over a long horizon, the other is that even if I do, I don’t know if I could trust it without seeing it.

This week: Axle 0.30, new docs; Sunnyday gains skills

Sun, 16 Aug 2026 07:00:00 GMT

Axle 0.30 is a big milestone in a few ways:

It marks the 30th release since I’ve started publishing the library consistently since June of last year. I typically release when I need to integrate changes into my core projects, and minor releases are when I make significant additions or breaking changes. That’s quite a pace, if I may say so myself.
More importantly, the compaction API has arrived at a good place. 0.30 solved a design conundrum I’ve been facing for a while, that is, what is the role of History — the dual objects of Messages and Turns — when it can be modified by an external actor. The answer is by removing Turn, the presentation layer, out of the Agent, and reduce the surface area of data that Agents work with. Now, the data model is coherent with a bit of conceptual tradeoff which we can bridge with built-in functions.

To celebrate, and to make sure I’m explaining the conceptual model well, the documentation site got a content revamp.

Sunnyday shipped skills. It’s something I’ve been wanting to do for a while, and having a concrete use case finally gave me a reason to built it.

The implementation went through a couple of cycles. The starting point was simple enough: it walks like a file and quacks like a file. But it soon became apparent that skills do indeed have a special status in an agent platform. I’ve settled on treating skills as files in the UI while handling them differently on the backend, which let’s me keep the UI and entry points simple. Though I doubt this is the last time I’ll have to think about it.

This week: Sunnyday Sandbox resume, Assistant; next Axle CLI?

Sun, 09 Aug 2026 07:00:00 GMT

On the Sunnyday side:

Agent sandboxes per session are fully resumable now, up to a maximum of 30 days. This sets up each agent up to take follow up commands, which will open up new avenues of interacting and correcting remote agents
Assistant is now in beta. You can now prototype, create, and update Agents using the Assistant. This is something I’ve been mulling on for a while; as much as I think the UI is remarkably intuitive, the blank screen problem is still tricky to design around. This provides a way to turn sketches into infrastructure builds really quickly.

Because the work was based on Axle (we shipped an update for this around the internal ontology — 0.29.0), and most of the work took advantage of features in Axle recently, it was quick to come together. For me, this sets up some further thinking around conversations as the primary UI that I’ve been mulling about, and I believe will make some of the deeper cutting features, such as self-serve custom evals, possible. AI Agents are very good at pulling existing snippets together.

I’ve been thinking about the next iteration of axle-cli. I’ve been building axle-code for fun on the side, and it has been illuminating to see what features require more work (harness) and what works “out of the box”. Spoiler alert: frontier AI models are coding models by default. I am going to need a more sophisticated CLI soon: it’s going to look a bit like Cowork but with the conveniences of task runners. More to come!

Prototyping the SDLC

Wed, 05 Aug 2026 07:00:00 GMT

AI generates code an order of magnitude faster than any human can. Hand-writing code is no longer a tenable proposition, and so the effort has shifted to doing whatever we can to hold AI code to our own quality bar. Some hand wave it away, comparing it to the evolution of C over Assembly, arguing that over time AI is going to be so good that we never have to think about the lower level code anymore. Others reach for the dark factory, where we validate the inputs and outputs and never care about what happens in between. The most developed version of this is a methodology now, promising to turn vibe coding into agentic engineering.

I’ve written about the conservation of complexity. The desired output is functionality, and the burden of knowing the details and verifying that it performs to the standard is something that still needs to be performed. In the agentic engineering case, the work shifts from software design and planning to a combination of bringing in the relevant contexts, using the appropriate set of prompt incantations, asking all the right questions, and rigorous testing.

I can see the allure. With the right process and guardrails, we can coerce AI to produce quality software. That said, the fragility of quality is often due to established processes being upended by unknowns, and it is impossible for us or anyone to know everything ahead of time. If the price of producing software approaches zero, we can take inspiration from practices from a recent past: prototyping.

In a formal Design process, we use prototypes extensively to validate desired behaviors and outcomes, which then gets handed over to the engineering process. Why not extend the idea: use AI to create prototypes, learn, and then generate specs, validation, and tests from them. More importantly, we discard the prototypes and rebuild the code from ground up using these produced artifacts. If anything changes with the artifacts, we discard the code and generate it from ground up again.

This separation between spec generation and code generation is important. A lot of bugs in software happen because of workarounds accumulated over time. Instructing AI to “make small changes” sounds good until it becomes a volley of patches layered on top of each other that becomes impossible to reason about.

This might sound a tad radical in a “we’ll rewrite it later” never world. However, consider the strengths of an AI agent: they are able to endlessly and tirelessly transform a set of words into another and conform them to an infinite suite of tests. Perhaps if production code is only produced with clean and locked down specs, we can maintain the rigor required of an industrial process. And notice the trick here, a fully deterministic set of requirements that produces a verifiable set of outputs sounds like a compiler. In the course of the rise of generative AI, we’ve been endlessly, tirelessly trying to coax probabilistic AI into deterministic outcomes, and maybe one day we will succeed.

This week: Sunnyday pruning; codebase knowing.

Sun, 02 Aug 2026 07:00:00 GMT

The week was all about trimming and pruning. Sunnyday went through an AI code review and came out with roughly a thousand lines less. Most of the savings came from the deletion of duplicated logic, and many of that from AI code written across different sessions.

I prefer a well refactored codebase because it simplifies the mental model that I have to hold in my head. AI doesn’t have to do that, it is tireless in how it reads and spits out code. That said, none of us are immune from the effects of a sprawling codebase—losing track of what things are supposed to be and subtle differences across branches.

I think a lot about the speed-knowledge tradeoff these days. If I go fast, which I can go much faster than I am today, I truly lose sight of what goes into my codebase. I maintain some oversight on code input, at least in codebases that I care about, and even then I’m surprised by some of the decisions when I do code review. Do we end up in a world where the discipline reorganizes itself into an outside looking in motion? Attention is truly the scarce resource of our age.

A Framework for Agentic Success

Tue, 28 Jul 2026 07:00:00 GMT

I wrote this down a few months ago while working on Sunnyday. Recording here for posterity.

There are 4 levels to understand if an agentic trace was successful. It breaks down to the following:

L0: did the run complete? These are binary outcomes at the infra level, basically if there are errors at the infrastructure level that prevented a run completion. Common examples are whether the LLM provider is at capacity, less obvious ones can be an example of a misconstructed tool call that loops forever.
L1: did the agent do what it planned? At this level, we ask the AI agent to pre-register what it thinks it’s going to need to do based on the information that is available at the message. Then we grade the completed run against the plan to check for gaps that we can fill in earlier.
L2: did it do the work well? Independent of the plan, did the agent encounter any obstacles when doing the work. Two separate tracks here. The first is if the run was optimal, where we detect for stumbling, error recovery, path efficiency, looping and flailing. Then there is the counterpart where we check if the tools and infrastructure is providing the right level of access and guidance to the agent.
L3: did the customer get what they wanted? This is a check on the work quality. The user started the agent to achieve a certain outcome; did the agent produce it? We start at examining whether deliverables are completed e.g., prose or pdf files, and then we can inspect the content of those things, whether they reflect the request, and furthermore we can delve into whether the content is accurate or aesthetic. This can probably be further broken down into multiple layers.

This week: Axle 0.28.0; evals, experiments.

Sun, 26 Jul 2026 07:00:00 GMT

Axle 0.28.0: a release long in the making focused on completing the compaction API and steering (changelog).

The hardest bit was finding the tradeoff sweet spot between complexity and API design. I first started with steer() – an API that allows the user to send a message that both cuts the queue and inserts in the first opportunity – which I backed out off because it introduced multiple queues in the scheduling internals. The compromise was to do less internally and expose a more granular API: stop() for a graceful stop, clear() to empty the queue, and chaining them together with a send() for steering semantics. I’m still finding the right line between opinionated and flexible; I’ll try the APIs out in a few Axle-Orbit experiments and see how they fare.

Other things shipped: make Axle baseline checks run in parallel; minor updates to Sunnyday fixing bugs and bumping up models and dependency.

Evals is on my mind. Even outside of the hype, having tools to slice and dice transcripts and corpus of transcripts feels useful. I’ve been thinking a lot about the how, and so far the most tenable way for me to make progress is to start bottoms up. I build a lot of fixtures to run Axle against LLM APIs as smoke tests. They are pretty rudimentary now, and perhaps iterating on those will lead me down more interesting conceptual paths.

One thing I’m trying to get myself to do now is to learn by doing. I have a tendency to want to think through problems thoroughly before attempting them. That’s one way of working through a problem. But sometimes, the smart and right thing to do is to stop thinking and start chipping at it. I need more of that in my practice.

A new resolve?

Thu, 23 Jul 2026 07:00:00 GMT

I’ve been thinking about what kind of work I want to do next. It then occurred to me: instead of thinking about problems, I can just work on them. The cost of making is dramatically lower these days, why not spend the time trying things and getting hands-on. The trick is picking problems small enough that I can finish. I’ll write up and post my findings here, so that I actually do.

The Law of Conservation of Complexity

Thu, 16 Jul 2026 07:00:00 GMT

Everyone else is talking about evals these days. Unsurprisingly, since we are at the phase where AI adoption is hitting critical mass.

There are two ways to know a system. You can know it from the inside, by holding the rule that generates its behavior: I built this, so I know how it works and what it will do. Or you can know it from the outside: when it does this, it needs to do that; quacks like a duck, is a duck and all that. Roughly speaking, it can be mapped to implementation versus specification.

In traditional software teams, software engineering and product management are the two equivalents. With AI doing most of the software writing these days, the location of the inside knowledge gets displaced. Prior to AI, the software engineer in the code base absorbs the burden of a lot of the complexity for free. AI removes the hiding spot, the thing still gets built, but no accountable human acquires the inside knowledge along the way.

I want to recall Tesler’s law of conservation of complexity. In Tesler’s formulation, there is a minimum amount of complexity that is either handled by the programmer or the user. In this case however, the knowledge of the complexity that is inherent to functioning software needs to be captured by implementation (inside knowledge) or verification (outside knowledge).

All the chatter around evals and dark factory patterns is about this. At the end of the day, someone needs to know that the system is doing what it’s supposed to do, and while the work is easier, I don’t know if the knowing can ever be.

Keeping up with the Robots

Thu, 09 Jul 2026 07:00:00 GMT

This morning, I was multitasking. I spent a few minutes making Claude Code go, and while it’s revving I’m writing in my paper notebook. Something catches the corner of my eye, I looked up and went to tend to the AI’s request. It whirls again, so it’s back to the notebook. Back and forth. As you can imagine, neither turned out particularly well, although if I were to be fair, the robot did a much better job than my writing. After all, I was only the one multitasking.

We have long known that multitasking reduces our cognitive abilities. There are numerous credible studies on this topic. Yet everyone is dual or triple wielding coding agents these days. Everyone feels more productive, and they are. They also say the work is not better ¹.

My observation is that the current crop of AI coding agents and models sit in the anti-flow zone of productivity: there is a little too much down time in between prompts, yet not enough to be able to effectively do something else. Once you hit enter on a prompt, a typical coding agent can take anywhere from minutes to tens of minutes, and while it’s doing its thing there is nothing much the human observer can do. We can try to follow along, but the terminal outputs are not really comprehension friendly. Of course we get bored and we multitask.

As a thought experiment, I wondered what would happen if coding agents are a magnitude faster². If we can get instant gratification it might solve the desire to let the attention wander. Yet at the same time, it raises an interesting question: if the robots can generate thousands of lines of code in a matter of seconds, then how are we able to really understand what’s going on? The temptation will be to do more and understand less since it’s the path of least resistance. Consequently, we will drown in systems that we do not understand.

When I ask people about this, everyone says that taste is going to be the thing that differentiates them. Make sense, since our perspective and judgement is what we really bring to the table and affect the world around us. That said, to be able to render accurate judgement requires us to understand the thing that we are judging. If our comprehension is being overwhelmed, then our judgement is what’s being overwhelmed.

I don’t know if there’s a neat little solution to this puzzle. My sense is that the status quo is not sustainable and things will need to change: either we develop tools to help us hold and understand more complexity, or we will have to delegate. Either the craft matters, or it becomes utilitarian.

The specific finding did not make it into the slides, but I have jotted it down here: Work Quality is felt to improve — except in engineering, which is neutral (3.0 vs design 3.4, PM 3.7). One hypothesis: engineers are no longer fully in charge of their craft. ↩
Anthropic shipped fast mode with Opus 4.6. Large scale mechanical refactors completed in a couple of minutes but it was expensive (6x). It almost crosses the attention span gap but wasn’t quite fast enough. I loved it though—the experience was remarkable. ↩

What Is Everyone Actually Doing With AI?

Tue, 30 Jun 2026 07:00:00 GMT

About a month ago I asked a friend if he was using any automations as part of his daily work. In response, he said he hadn’t used much AI other than the obligatory chatbots, and that he felt behind. It made me think about what I take for granted in my own AI use, and really ignited my curiosity about how everyone else is using AI.

As a designer, what do you do in these circumstances? You ask people. So, I made a survey on how people use AI at work and how they feel about it. This survey was sent to friends and a few other social and professional groups that I’m in.

107 people took the survey. High level findings: people are using a lot of AI at work, and AI replaces or augments the main work that they do. Respondents like it, and most surprisingly, software engineers who use AI to do a lot of their core work still think using AI makes them more valuable. One caveat is that these respondents are AI enthusiasts, so if anything these numbers represent the leading edge, not the average. Here are the full results:

A note on methodology and my own AI use

This being a survey about AI, I wanted to be really cognizant about how I use AI in this process. Overall, the start to finish took over a month. A few days to write the survey. One week of procrastination. A little over two weeks of result collection, and about a week of result analysis.

The initial survey was written in conjunction with Claude. I penned down a very rough first draft, fleshed out the structure with Claude, and iterated question by question until we got it tight. I knew from the beginning that the survey needed to be 15 questions or less, so the main decision points were making sure each question pulled its own weight, and balancing the types of questions so I got both comparable data points and rich insights.

An important precursor to analyzing the results was registering my hypotheses. I knew that once I set eyes on the results my “findings” would be colored, so it was important to figure out what I expected. From the initial survey I got Claude to ask me a bunch of questions about my expectations. I answered each one of them and registered what I thought the answers would be. The results turned out pretty much in line with the hypotheses, differing in magnitude, with the exception of the finding above where the people who do their core work with AI still find that using AI makes them more valuable.

Analyzing the results took a few passes. The first was making sense of all the quantitative responses. My tool of choice for this is Jupyter notebook, and I used Codex and Copilot to help build most of the notebook out. I first graphed out every question, then broke each one down by demographics.

Once I was satisfied with all the quant data, I then took a pass on the qualitative ones. I first read them individually to get a sense of what the overall picture looked like. Then, with Claude, we coded the rows together. This was an iterative process of asking Claude to come up with the code book, me going through row by row to see if it fit, and iterating with Claude to refine both the coding and the code book. I thought this would be easy with AI; it was easier, but it was also tedious. To finish off, the transformed data was brought back into Jupyter and graphed.

When everything was done, I looked through all the graphs and wrote down everything that stood out to me. After that, I handed an AI all the data and my findings, and fleshed them out. I ended up with about 3 pages of bullet points.

To construct the final deck you see above, I first highlighted the most compelling findings and then worked with Claude to construct a narrative arc for a presentation. The deck was created in Google Slides by hand, alas. The charts were created in Google Sheets with data extracted from the source worksheet by Cowork.

It was fun, interesting, and ended up being a lot more work than I had expected. I would say that I benefitted immensely from having AI as a collaborator on both the thinking and the tedium of this exercise. AI is not always or even often right, but by having it give me something to edit and start from, it has made it easier to keep making progress. Without AI, I wouldn’t have been able to achieve the amount of rigor, and frankly just spend the amount of time and effort on a project like this.

So was my friend right about being behind? Depends on who he compares himself against. Yes if it’s against the bleeding edge of AI adoption. And an empathetic no, because managing humans is not something AI is good at.