two weeks later, I had the highest publicly reported score in 5.5x fewer tokens than the next-best agent.

Each ARC-AGI-3 game is played on a 64x64 grid and contains 6-10 levels of increasing difficulty, each with a limited number of actions to beat it. an agent sees the grid (no other context), figures out how to play, and gets scored on how efficient it is relative to a human baseline (Relative Human Action Efficiency, RHAE for short).

july 5: seems simple enough

I cloned RGB-Agent (read, grep, bash) and baseline1 as reference agents. RGB was mentioned in the tweet and had the best score on the three preview games released in March; baseline1 was the current top scoring agent on the community leaderboard and operated by building a durable Python world model for each game, running inside codex.

I played through a couple of the simpler games by hand and thought “this doesn’t seem that complicated, I don’t think an LLM would need a full world model to solve it”. so my plan was to re-implement RGB-Agent using ThinHarness (my minimal agent harness framework), add a few improvements on top, and show that some subset of the 25 games could be solved more simply than baseline1 demonstrated--no executable world model, no coding agent harness, just a model in a loop with a python tool.

first run: ft09, a “lights-out” style game, with gpt 5.5 high, because RGB had already beaten it in only 78 actions. my port beat levels 1–4 in 46 actions, then got stuck on level 5 and burned 130 actions before hitting the $10 cost cap I’d set.

july 6-8: retrodict before you act

the traces showed it was spending actions to test hypotheses that were answerable with the existing log file, so I added retrodiction to the prompt: check every hypothesis against the recorded history in python before spending actions on it. additionally, every submitted action must carry an expected result, so a missed prediction cancels the rest of the batch instead of wasting additional actions. (the agent’s name, Retrodict, is based on this mechanic).

these changes improved behavior, but the agent still got stuck on level 5, which seemed consistent with RGB’s high variance and early hypothesis lock-in (as per their blog post). other games (vc33, sp80) showed the same pattern, where the agent solved early levels before hitting a wall.

after every run I had claude dig through the traces, and the issue was never a simple bug or one-line prompt change: the agent read the board correctly, retrodicted, and came up with reasonable hypotheses. the failures were subtler: hypothesis lock-in, planning through slightly incorrect models, inability to cut losses and reset. it understood the game but lost anyways.

july 8-9: vision and the first win

the fixes were all going to be substantial, and $10-20 per run meant expensive iteration. so I spent a day trying to find a cheaper model that was decent enough to iterate with. I tested qwen, minimax, grok, and sonnet, but none of them got past the first level of sp80; gpt 5.5 beat 4/6.

sp80 was a game baseline1 hadn’t fully solved; I just thought the first couple of levels would be easy based on playing it by hand. to be more systematic, I made an “easy list” of baseline1’s wins sorted by fewest actions. r11l was towards the top at 182 actions, so I ran gpt 5.5 on it before trying the cheaper models, and was shocked that the agent couldn’t even solve the first level--the traces showed that it never understood the goal (move the endpoints so the tethered purple ball reaches the purple target).

the goal felt obvious to me from the game’s appearance, so I sent a screenshot to an image model with no other context--it completely understood the mechanics and the goal. this led me to add an “image prime” step at the beginning: the first frame goes to a vision model, which writes a description, the likely goal, and a hypothesis of how to play. armed with this, the agent was able to... beat two levels. progress, but still below expectation.

next on the easy list was lp85, and the agent finally got a win! 8/8 levels in 125 actions, fewer than baseline1’s 190.

trace analysis showed hundreds of python calls re-deriving the same plumbing: parsing the log from scratch and implementing board diffs inline. so I gave it a small arclog library, a scratch/ folder to persist its own per-game helper code, and a [DIFF] block in the log listing exactly which cells changed at each step. that got r11l to 5/6, but it cost $36.51 on gpt 5.5 and the cheap models clearly weren’t strong enough, so I was worried that making any real progress would be too expensive.

july 10: a new model

then gpt 5.6 released.

perfect! cheaper access to gpt 5.5-level intelligence and higher max intelligence with sol!

but the 5.6 models were somehow worse.

5.6 terra was supposed to be a 50% cheaper gpt 5.5 equivalent, but in my initial probes it got stuck on level 2 of r11l; luna actually made it to level 3 once, but still not great. sol did well, but it was the same price as gpt 5.5, so I continued pushing on the cheaper models.

the traces revealed that they both understood the game perfectly, they were just acting super inefficiently compared to 5.5: instead of sending a whole batch of actions against a hypothesis, they sent a single action and looked at the result, over and over.

so I finally read the system prompt for myself, and it was obviously a mess. everything important lived under a single jumbled “## Method” section: tooling tips, perception warnings, epistemic method, and environment rules. I reorganized it into logical sections until it was actually comprehensible, then kicked off runs with terra and sol, same high effort as usual.

july 10-11: the top score

terra: 4/6 (crashed due to a parsing error in my runner code). sol: 6/6, my first-ever win on r11l, for $5.72. the prior gpt 5.5 run got 5/6 for $36.51.

it felt like magic.

that evening I tried 7 more games with a $12 cap each: 6 wins, and the seventh got close but hit the cap--on a game baseline1 had also failed. I let claude run the remaining 17 games overnight. by morning: 13/25 games solved, 65.13% mean RHAE, $270.34 total spent. baseline1’s amended score, documented in their repo, was 58.12%; the other highest entry on the community leaderboard was 63.1%, at a total cost of $4,788.

suddenly, I had the highest publicly reported score.

july 11: oh wait

until I realized that at 4:51 AM on july 10, 17 hours before the sol breakthrough on r11l, baseline1 had committed a v1.5 run: gpt 5.5 xhigh, 82.01% mean RHAE, 20/25 games solved.

july 12: memory loss

I had subagents analyze the traces of the 9 games that baseline1 v1.5 had beaten but Retrodict was still failing (it beat 2 games that baseline1 failed). the verdict: sol “couldn’t reliably forward-simulate hidden, temporal game dynamics”, and a full world model would help, but memory was the real blocker--I had context reset at 150k tokens, and after every reset it had to re-derive the rules of the game.

so I added playbook.md: a “short curated file holding only your durable, distilled knowledge,” carried across resets and maintained using ThinHarness’s built-in write/edit tools.

at first it was split between “Confirmed” knowledge and a “Current level” scratchpad; this helped beat two of the 9, but the agent still got stuck because it was locking in confirmed knowledge early that was actually wrong, which made solvable levels look impossible. I reframed the playbook as “Working model” / “Working memory” to prevent implied certainty, and 4 more games fell.

july 13-14: a real shot at the top score

at this point 19/25 games had a win on some version of the harness, against v1.5’s 20/25, so getting a real top score seemed possible. I ran the updated version of Retrodict overnight on the 16 games that it hadn’t tried yet, $25 cap each. when I woke up: 8 prior wins re-confirmed, the 6 never-solved games capped out, and two prior wins had regressed versus the pre-memory agent.

I re-ran the two regressions with no harness changes and they easily succeeded; I resumed three of the capped runs with more budget and two of them won.

july 14, ~7:30 PM, nine days after reading the tweet: 21/25 solved, 84.52% mean RHAE vs. baseline1’s 82.01%. the highest reported score.

july 15-16: not again...

it took some time to organize everything and put together my official submission. I made the PR, looked at the list of PRs on the leaderboard repo, and--

baseline1’s repo was untouched but their leaderboard PR had been updated the previous morning: gpt 5.6 sol xhigh, 98.97% mean RHAE, all 25 games solved. again, my score was never truly the highest.

july 16-17: world models as an escape hatch

that same night I was back at it. my hopes of taking the top spot had vanished, but that wasn’t my original goal anyways. looking at the four games my agent had never beaten, I had to admit that it seemed like an executable world model would actually be helpful for them: each game stalled on complex levels requiring long action sequences that were hard for Retrodict to test without spending actions.

the fix was enabling escalation: after 300 actions or two self-resets when stuck on a single level, a prompt directive gets sent that tells the agent to create and test an executable simulator with confirmed rules.

this was a move towards baseline1’s full world modeling approach, but as an escape hatch rather than a default. this allowed the agent to solve easy games cheaply and still beat the more involved games. three of the four remaining unsolved games were finally conquered; the fourth turned out to only need a re-run.

july 17: the second paper

the next evening, baseline1 restructured their repo around a second paper, Do Coding Agents Need Executable World Models, Simplification, and Verification to Solve ARC-AGI-3?

this paper contained a control version of the harness that only used a textual world model called twma (textual world modeling agent): no required executable simulator, durable rules in a text file. they then layered an executable world model, simplification, and replay verification on top.

on sol at max effort twma did quite well, beating 25/25 games, 95.97% RHAE, using roughly a third of the tokens of the executable world modeling agent (ewma).

july 18-19: the final run

taking my best runs on every game across all harness iterations, my ~92% RHAE was still well below 95.97%, but I was using ~2x fewer tokens than even twma.

in theory, Retrodict should have been able to at least match twma’s score; it had the executable escape hatch in addition to durable text memory. unless... I just did a worse job harness engineering?

I realized there was one lever I hadn’t pulled yet: effort. I had been using 5.6 sol on high effort, and never thought to change it since it was token efficient and doing well. baseline1 used xhigh (ewma) and max (twma).

so I did one last run of all 25 games using max-effort sol and the final version of the harness.

99.86% mean RHAE, 25/25 games solved. 660M tokens, 5.5x fewer than ewma’s 98.97% run and 1.8x fewer than twma’s 95.97% run. finally, 14 days after originally learning about ARC-AGI, I had the actual1 highest score on the benchmark.

official scorecard link, repo link

where the token gap comes from

full comparison of results:

RHAE is action efficiency, so Retrodict and ewma xhigh use a similar number of actions (7,703 vs. 8,347) for their very similar scores; nearly all of the 5.5x token gap is tokens per action: how much thinking each move costs.

for ewma, the token gap is so large because its simulator must be complete and is strictly verified: it has to correctly predict the value of all 4,096 cells in the 64x64 grid. a lot of effort is spent on being pixel-perfect rather than on core game understanding; on sb26, it spends 307 lines of code to model the cell rendering vs. 85 lines modeling the actual internal game mechanics.

Retrodict, on the other hand, only has to specify a small set of cell assertions for each action (median of 1 cell) that would falsify its hypothesis if incorrect. sb26 is the most extreme example of the inefficiency introduced by the strict world model: both baseline1 and Retrodict scored a perfect 100 in similar action counts (140 vs. 133), but baseline1 spent 68M tokens to my 5.8M--an 11.7x difference.

for twma, the token gap mostly exists because it can only play a single action per llm call, while Retrodict can batch multiple actions in a single request. this results in ~2.9x more llm calls but each call has ~0.6x as many tokens because it’s not doing as much work; 2.9x more llm calls * 0.62x tokens per call = ~1.8x more tokens overall.

an untested hypothesis

it wasn’t until july 20 that the baseline1 repo added the arxiv link for the second paper, whose conclusion left one thing untested:

it may be possible to improve the less resource-intensive textual variant enough to narrow or even reverse its performance gap with the verification variant. We did not test this possibility, so it remains a hypothesis for future work rather than a conclusion of the present study.

so it turns out that this whole time I was unintentionally testing the hypothesis of whether a resource-light harness based primarily on text could match the performance of a strictly verified one.

when I started, my pitch was that some of these games could be solved more simply than by using a full executable world model, with a minimal harness instead of a full coding agent. unexpectedly, and with the help of a new class of model intelligence, “some” became “all” and my agent ended up at the top of the leaderboard.

It sounds great: drop your articles, papers, and notes into a folder, point an agent at it, and watch it compile a living wiki—interlinked entity pages, summaries, contradictions flagged, the whole thing self-maintaining.

Let me save you some time. It’s not as useful as it seems.

In 2022, before LLMs were any good at editing markdown, I got deep into Obsidian. I graduated college early and had time before starting my first job, so I spent four or five months building the perfect knowledge base to help me prepare. Then I started the job and never opened it again.

Obviously, things are different now with the state of AI. The burden of maintenance is entirely gone; all the articles are right about how easy and effective it is to create an impressive knowledge base.

But cost was never the bottleneck. They’re hyping up a solution to the wrong problem.

An LLM can connect note A to notes B and C in your vault and answer questions across hundreds of curated sources. None of that changes whether you’ve internalized any of it. AI can’t be in the room when a coworker says something at lunch that should connect to one of those notes—the connection has to happen live, drawing on knowledge that’s actually in your head. People have been writing “I deleted my second brain” pieces for years; having AI build it for you doesn’t fix the underlying problem that storing something isn’t the same as understanding it.

In fairness to Karpathy, read his original gist if you haven’t already. It’s narrower than the posts that followed. He’s explicit that the pattern is for “topics of research interest”: going deep on a bounded subject, building a companion wiki for a book, doing competitive analysis. An LLM wiki is great for that work.

Even outside those use cases, I’m not saying this trend is a bad thing. It’s fun to set up, the results are impressive, and you still gain some knowledge just from curating the sources. But nobody in the recent craze talks about what to actually do with the wiki once it exists.

I do use Obsidian, but Readwise Reader has been my primary interface for the past couple of months. It’s an AI-friendly tool (with an Obsidian integration) that makes it easy to ingest, consume, and engage with content from anywhere—Substack, Twitter, personal blogs, company news pages, etc.

My personal knowledge system is still a work-in-progress, but it’s pretty light and is focused primarily on understanding. I’d rather slowly read and digest twenty articles than build a wiki of five hundred that I never truly understand.

You usually read on a Kindle Paperwhite, but on the way to dinner you only have your phone with you, so you use the Kindle app on your phone while on the subway. You get off the subway and have an 8 minute walk to the restaurant, during which you can no longer read.

Wouldn’t it be nice to listen to an audiobook on that walk? But you don’t usually listen to audiobooks, and you only really need it for a few minutes, so you don’t want to buy the whole audiobook. Plus, your book isn’t Whispersync-for-Voice enabled, so even if you had the audiobook and listened, your progress wouldn’t sync—you’d have to manually find the right spot in the book.

This very relatable scenario is just my life, so I built an app to generate audiobook snippets on-demand with AI—and they always sync.

1.0 Decoding Kindle

My original idea was to have an app that would automatically swipe/screenshot the Kindle app and use OCR to extract text, but Apple doesn’t allow that level of device control (for good reason). So I had to find a way to programmatically get the content of the book and sync reading progress.

1.1 Content Deobfuscation

After a bit of searching, I discovered that Kindle ebook files download as .tar and have to be deobfuscated—the actual page images are embedded as a series of XOR’d glyphs rather than plain text. I got lucky on timing; PixelMelt had just posted an article on how to reverse engineer the obfuscation.

I did this project in November and had been hearing good things about Codex so thought this would be a nice opportunity to give it a try; PixelMelt didn’t publicly share the code so I’d have to recreate it. I gave both Codex and Claude Code the article content and let them run with it. Both failed pretty miserably1, but Codex failed less miserably, so I decided to switch over for the rest of the project.

Amidst its failure Claude did uncover a more recent article with improvements to the original deobfuscation methodology—render all the glyphs, stitch them together into their page structure, screenshot the page, OCR the screenshot. Armed with this new approach + some more intentional instructing, Codex got the job done pretty quickly.

1.2 Kindle Access

That solved extracting text once I had the .tar file, but I still needed to be able to programmatically download the file and update reading position in the book. I pretty quickly found the kindle-api library for access to the Kindle Web API, but there were two problems:

1. Only books you buy on the Kindle store show up in the web reader, but I purchase most of my books elsewhere

2. The library only supported retrieving high-level book info

I spent ~45 minutes with mitmproxy to try to reverse engineer the Kindle Mac reader’s API, but it was a lot harder to figure out than the web API and I didn’t want to spend the whole project just reverse engineering, so I decided that being limited to books bought on the Kindle store was fine.

The original repo has you log into the web reader, inspect element, and manually copy cookies (valid for a year) from the network requests. The endpoints I needed had additional shorter-lived tokens, though, so I needed a better way to collect the info.

Rather than trying to automate with puppeteer/playwright and beat Amazon’s captcha, I just put an embedded browser in the iOS app—the user logs in manually, and the app grabs the required cookies from the network requests.

2.0 Building the App

Now that I had all the pieces, time to put it together!

2.1 Architecture

I used Fastify for the server and SwiftUI for the iOS app, with WKWebView + injected JavaScript to capture Amazon credentials from network requests. The server calls my Python deobfuscation code as a subprocess and relies on my fork of kindle-api for Kindle access.

The initial version was minimal: download the book content, convert it to text, and serve text chunks to the app. Before integrating text-to-speech and reading progress, I had to make a decision about data storage.

There are a lot of artifacts to manage—raw .tar files, extracted JSONs, page images, OCR text, audio files. I could have set up S3 or a database, but that felt like overkill for a self-hosted single-user app. Instead, I went with an the simplest option: store everything in a local data folder within the server. If the server dies, so does my data, but for relatively ephemeral audiobook snippets that’s probably fine.

2.2 Audio & Position Sync

I used ElevenLabs for text to speech; they have a with-timestamps endpoint that provides the necessary character-level timing information to be able to sync reading progress with position. I stored mapping of audio timestamps to Kindle position IDs at 5-second intervals, so the app knows where to update progress as playback advances.

I then added a frame-synced listener to the audio playback that checks every frame if the current time has crossed a benchmark checkpoint. When it does, it hits the /books/:asin/progress endpoint with the corresponding Kindle position ID, syncing the progress back to Amazon.

3.0 Debugging

Unsurprisingly, getting the above functionality working wasn’t as painless as I made it sound.

3.1 Oh you want another book?

Up to this point, I had been testing on the only book that I had in the Kindle web viewer: Wind and Truth by Brandon Sanderson. I figured it was time to expand, so I got a free sample book and ran it through the app, but the content download failed. I compared sample vs. free vs. paid books, but only Wind and Truth was working. Looking at full book metadata didn’t reveal anything.

Codex actually wasn’t much help here, I ended up discovering the issue myself: renderRevision, one of the required arguments for the content download endpoint, was hardcoded to the value for Wind and Truth. I guess it slipped under my AI-slop radar. It’s not the craziest thing; most of the args for the download endpoint are hardcodes (like fontSize, height, width, margins, etc.), and there’s also a kindleSessionId parameter that’s just a randomly generated UUID.

3.2 Corruption

Once I had that fixed, the download worked, but I ran into another error: the .tar download was incomplete and didn’t always have the necessary json files that we needed to reconstruct the text.

Codex did some analysis of the file contents and discovered that all the files were present in the .tar, but some of them were corrupt and didn’t get properly extracted. It thought the issue was on Amazon’s side, but I wasn’t convinced. After some testing, I discovered that copying the raw cURL request made by the browser worked, but making a request from my server with the exact same parameters would fail.

That narrowed it down to the way my server sent requests vs. a raw cURL, and I finally figured it out: the TLS proxy. All requests from my server were being proxied through an external tls-client-api, which is required due to changes in Amazon’s TLS fingerprinting in July 2023 (discovered by the original developer of kindle-api). The proxy mimics Chrome’s TLS fingerprint so Amazon’s servers accept the requests—requests from standard Node.js libraries get rejected because their TLS handshake doesn’t match a real browser.

I hadn’t changed any of the TLS proxy code, and the default setting was to treat every response as text. This worked fine for the original kindle-api functionality of fetching book data, but breaks with tarballs. It basically tries to shove the binary tarball into a UTF-8 string before returning it to our server, which then has to encode it (sometimes unsuccessfully) before writing to disk. Once I added a setting to treat the .tar responses as binary, everything worked perfectly.

4.0 Deployment & Polish

There was still a lot of functionality to add, but the core pipeline was working, so I deployed the app to make sure there wasn’t anything I failed to consider from a deployment perspective.

4.1 Server Deployment

Deploying the server to fly.io ended up being pretty easy. The Dockerfile uses a multi-stage build to install three runtimes—Node (for the server), Python (for text deobfuscation), and Go (for the TLS client)—but otherwise nothing fancy.

As an aside, if you haven’t used fly.io I would highly recommend. It’s not as fully featured as AWS or Azure but is so much easier to work with and makes deployment a breeze for side projects.

4.2 iOS Signing

There were a few options for bundling the iOS app and actually testing it on my phone vs. the iPhone simulator on Mac. Since I’m not planning to publish this to the app store and didn’t want to pay Apple $99/year for a developer account, I went with the free option—sign the app every 7 days when the provisioning profile expires.

There’s a ton of permission/certificate stuff to go through on Mac that I hadn’t done before, but eventually got it up and running! On-demand audiobooks for Kindle that properly sync my reading position.

I was also tired of the empty app icon so I quickly had ChatGPT generate one for me; it looked exactly how you would expect when asking AI to make a “minimal app icon for AI generated audiobooks”:

4.3 Post-Deployment Fixes

The first thing I noticed after deploying is that the app slowed down a lot when using the remote server hosted on fly vs. when I was testing locally. Turns out Tesseract OCR is very fast on my Macbook M4 Pro but not so fast on a tiny 1x shared CPU machine. Easy enough to switch over to using an API from ocr.space, although I had to change from their default engine to “Engine 2” to handle the multi-column text and maintain proper reading order.

Other updates:

• Logging: I was getting by with the default logging on the Fastify server / TLS proxy but it was getting a bit painful, so I added proper logging

• Security: Someone could theoretically clone my repo, point their app at my server, and use up my TTS credits, so I added a simple server API key (login would have been overkill)

• iOS App: I cleaned up the app code to use MVVM architecture and cleaned up the UI a bit

5.0 Additional Features

Time for a few quality-of-life improvements.

5.1 Cartesia + LLM Preprocessing

I was getting close to the credit limit for ElevenLabs and their cheapest subscription didn’t allow for usage-based pricing, so it was time to add another TTS provider. Cartesia had a really impressive demo on their site and is cheaper than ElevenLabs, so I decided to give it a try. They provide time benchmarks at the word level rather than the character level, but that was fine given that my app only sends progress updates every 5 seconds.

To take advantage of Cartesia’s emotion and pause features, I added an LLM layer that puts emotion tags and pauses in the text (along with cleaning up the occasional spacing mistake from OCR). I was really excited about emotion, but it only seemed to work with shorter texts where the entire thing has the same emotion. From the documentation:

Emotion control is highly experimental, particularly when emotion shifts occur mid-generation.

Given that these are long book passages with emotion shifts throughout, it’s not surprising that it didn’t work2. The OCR cleanup + pauses still helped a bit but it takes a while (even with small models like gpt-5-nano), so I left it in as an optional step.

5.2 Partial Generation

I was tired of always generating the full ~8 minutes worth of content, so I added duration selection (1-8 minutes). This had some interesting implications.

First, since the downloaded content covers a fixed range (typically 8 minutes worth), I needed to slice the text to the appropriate length for the requested duration. I used a simple linear proportion—if you request 5 minutes, you get ~5/8 of the text—and aligned the slice to the nearest sentence boundary so audio doesn’t cut off mid-sentence.

Second, there’s the question of overlap: what happens if you generate 5 minutes starting at position 50000, then later request 5 minutes starting at position 52000? For simplicity, I store multiple audio artifacts per provider per chunk, and only reuse an existing artifact if it fully covers the requested range. So if you have audio covering 50000-55000 and request 52000-57000, it will regenerate (the existing artifact doesn’t cover past 55000). This avoids the complexity of stitching audio files together.

5.3 Finishing Touches

A few final additions:

• Library: Delete or re-play previously generated audiobooks

• Resume: Use current Kindle position to automatically seek to the right spot when resuming playback of a partially-complete audiobook

• UI: Proper overhaul to feel more like an iOS app with different tabs; everything was previously on one screen for easier debugging

The final result

So finally, after much strife, I achieved what I sought after: on-demand AI audiobooks that would sync properly with my Kindle.

Was it worth it? Let’s break it down:

I think the table speaks for itself.

(See here for the full codebase)

That assumption no longer holds.

Progress has been made, but AI will never truly master PowerPoint because PowerPoint was built to be manipulated by hand, not generated programmatically. This is just one example of a broader trend: formats that are purpose-built for AI to create and edit will eventually displace those designed for humans alone.

Why powerpoint is hard for AI

Consider a task that takes two lines of CSS but requires AI to perform five separate calculations in PowerPoint: making items equally spaced.

HTML/CSS: Represents Intent

.container {
  display: flex;
  justify-content: space-evenly;
}

This code says: “arrange the items inside this container with equal spacing between them.” The browser figures out all the pixel math. If you resize the container, the spacing recalculates automatically. The AI doesn’t need to know the container width, the number of items, or do any arithmetic. It just states the intent.

PowerPoint: Represents Outcomes

Under the hood, a .pptx file is just a ZIP archive containing XML files—specifically, a format called Office Open XML (OOXML). Every shape, every text box, every image is defined in XML with absolute positioning:

<p:sp>
  <p:spPr>
    <a:xfrm>
      <a:off x="1676400" y="914400"/>    <!-- Position in EMUs -->
      <a:ext cx="1219200" cy="1219200"/> <!-- Size in EMUs -->
    </a:xfrm>
  </p:spPr>
</p:sp>

To create “equally spaced” items, the AI must:

1. Read the slide width from the slide size XML element

2. Read each shape’s width from the <a:ext> XML element shown above

3. Calculate spacing: (slide_width - sum(shape_widths)) / (n + 1)

4. Calculate each shape’s x position: spacing + sum(prev_shape_widths) + (i * spacing)

5. Write each x position to the <a:off> XML element shown above

“Equally spaced” and “arbitrarily placed” require the exact same amount of work; they’re just different numbers. There’s no semantic distinction in the data model.

You could create friendlier wrappers and APIs around the XML content, but that’s a clunky workaround rather than a proper solution to the problem.

What’s the alternative?

1. AI-native presentation software

Products that are built with AI in mind can design their internal object model in a way that makes it easy for AI to create and modify.

Gamma is the best example of this approach. Recently valued at $2.1B with $100M in ARR, they’ve grown rapidly and have a very different product—instead of absolutely-positioned shapes, they use scrollable, block-based ‘cards’ that feel more like web documents.

They don’t provide a ton of visibility into their internal representation, but the focus on structured content + strong AI features make me confident that it’s significantly easier for AI to work with than PowerPoint’s OOXML.

2. PowerPoint as an export format

Even if you’re set on creating a .pptx file, using PowerPoint isn’t necessarily the best way for AI to get there.

Anthropic’s Claude Code skill has the best output of any general-purpose AI I’ve seen, and it creates slides by writing HTML that gets converted into a PowerPoint file using a ~1000 line conversion script built on PptxGenJS, Playwright, and Sharp. The data model that the AI actually works with is HTML, not PowerPoint1.

If this pattern grows, PowerPoint could end up as a legacy export format rather than the primary place people actually do work.

3. Code-native presentations

If LLMs are great at writing HTML, why convert to .pptx at all? Reveal.js is an open-source HTML presentation framework that makes slides first-class web documents. The advantages:

• Makes AI creation and iteration easy with plain HTML+CSS and DeckTape for quick slide screenshots

• Includes the core features presenters expect: speaker notes, slide transitions, progressive content reveal, PDF export

• Offers new features that traditional software can’t match: syntax-highlighted code with line-by-line reveal, vertical slide stacks for drilling into subtopics, and embedded interactive content

The one thing Reveal.js lacks out of the box is an interactive visual editor, but Slides.com attempts to fills that gap2 —it’s a GUI built on top of Reveal.js. This inverts PowerPoint’s approach: instead of building a visual editor first and treating the data model as an afterthought, you start with an AI-friendly format and layer human editing on top.

I put together a quick Claude Code skill for Reveal.js (revealjs-skill) and put it head to head vs. Anthropic’s pptx skill to generate a pitch deck for a fictional legal AI startup. Here’s the prompt I used, pptx skill output, revealjs skill output.

I’m a little biased but would argue that the Reveal.js output looks better, and it took less time to generate; see the footnotes for a full breakdown3.

Beyond PowerPoint

Presentations aren’t the only category where legacy formats aren’t ideal for AI; this pattern appears across productivity software.

Documents

Word’s .docx format has a similar structure as PowerPoint: complex XML with formatting specified in separate blocks per sentence/word/character. Word focuses on storing the visual rendering details of the content, which aligns with a human-designed editor, while Markdown has been used in codebases for decades and much more concisely stores the content + structure.

Markdown-like editors (Notion, Obsidian, GitHub) are much more common than presentation editors and it’s generally an easier format to convert to, so there’s less friction—Markdown is already a go-to for AI-generated reports or documents, with exports to Word becoming less common.

Spreadsheets

Continuing down the Microsoft Office suite, the same pattern is emerging for Excel.

Univer is an open-source framework for building “AI-native spreadsheets” and currently leads the SpreadsheetBench leaderboard at 68.9%, beating Microsoft Copilot’s Agent Mode (57.2%) and Claude (42.9%) by a significant margin.

Unlike add-ons that layer AI directly on top of Excel, Univer is a totally independent spreadsheet engine built from the ground up for natural language interaction. It can import and export .xlsx files, but that’s legacy compatibility rather than a primary format.

Business Intelligence

Tableau and Power BI have historically dominated the dashboarding market, but their formats have limitations similar to PowerPoint. Tableau’s .twb files are XML documents encoding visual layouts with absolute coordinates, and Power BI’s .pbix files bundle similar positional data with a proprietary query language. Both were designed around drag-and-drop interfaces where humans visually arrange charts on a canvas.

A growing category of “BI-as-code” tools take a different approach. Evidence.dev uses SQL for queries and Markdown for layout; Lightdash defines metrics in YAML and integrates with dbt. Instead of encoding “place this bar chart at coordinates (1200, 400),” these tools let AI write SQL queries and declare charts in Markdown or YAML—formats it already understands.

Conclusion

In the short term, building to extend and automate legacy human tools makes a lot of sense; it’s where everyone is already doing work. In the long term, though, if AI is really going to transform and potentially automate knowledge work as we know it—why in the world would it be using PowerPoint?

Instead of doing that, I’m going to synthesize insights from across the discussion in one place—why tech bubbles form, how they pop, what feels different about AI in that context, and how to respond.

AI is going through the same fundamental cycle as past technologies, but it’s unique because it has two distinct bubble mechanisms: inflated valuations and infrastructure overbuilds. Regardless of whether the bubble pops, there’s going to be real disillusionment, but in the long run AI will still be a transformative technology.

Let’s dive in.

Why bubbles?

Things feel a little crazy right now—valuations, marketing, rush to put “AI” on everything—and that’s to be expected. Virtually every transformative technology goes through a hype cycle, and we’re squarely in the “peak of inflated expectations” as defined by Gartner.

The AI companies recognize this and are using hype as a business tool to allow them to continue raising huge amounts of money for as long as possible. The goal: survive the crash and initiate the slope of enlightenment by making a breakthrough before funding runs out.

AI has two additional elements that bring the hype levels even higher:

1. It requires expensive infrastructure buildout, which brings in Perez’s theory of installation-deployment: installation involves a finance-led frenzy and over-investment in infrastructure that ends in a crash; after a turning point and realignment, deployment sees economy-wide diffusion and productivity gains

2. It’s the first technology where it feels like there might be a path to significantly compress the trough: AI could spur a research productivity flywheel that shortens iteration cycles through faster coding and discovery

How bubbles pop

Eventually the hype dies as the technology fails to live up to inflated expectations; a crash follows and we enter the “trough of disillusionment”. This crash often comes with the popping of a bubble, which can occur in two distinct ways1:

1. Valuation bubbles pop when overpriced companies collapse due to weak fundamentals

2. Infrastructure bubbles pop when overbuilt capacity far exceeds demand

The dot-com era is a classic example of a valuation bubble, and the 1990s telecom build-out followed an infrastructure bubble.

Looking at these past technology cycles2 helps illuminate how AI has potential for both.

A brief history

The two kinds of bubbles correspond with different technology cycle types: infrastructure buildouts and software-led tech.

Infrastructure Buildouts

• Telecommunications (late 1990s): Telecom companies expected unlimited demand but built too fast and capacity went unused; the cheap bandwidth that remained was used to power the cloud + mobile revolutions

• Railroad (early 1870s): Subsidized “essential” railroads were built far too quickly, and with profit a long way out, funding dried up; the important lines survived and the US benefitted heavily from them

Software-led Tech

• Dot-com (mid 1990s-2002): Hype for the internet outweighed the need for presently strong financials, but shallow business models eventually failed; it wasn’t until later that massively profitable e-commerce, SaaS, and ads businesses emerged

• Mobile Phones (early 2000s)3: Having “the internet in your pocket” was supposed to “change everything”, but the technology wasn’t ready; several years later the real revolution actually began with the iPhone 3GS

Not every hype cycle has an associated major bubble pop (e.g. mobile phones), but those that do are either an infrastructure bubble or a valuation bubble. AI is unique because there’s clear potential for both; inflated company valuations could crash and/or we could have a significant amount of excess data center capacity.

Is it a bubble?

I don’t think we’re in a bubble yet, but the current direction of travel raises concern4.

The analysis I find most helpful for understanding the current state + trend is Exponential View’s “gauge” framework. It uses five indicators that can be monitored and compared across current + historical situations to evaluate bubble risk; two reds = trouble, three reds = imminent trouble.

We’re already seeing slowdowns in progression of AI and these indicators have worsened from September to now5, so unless a major breakthrough comes soon it’s unlikely that the technology will live up to inflated expectations. We probably have significant work left to do and will go through a proper trough of disillusionment—which could either be associated with a bubble pop or a slow deflation.

If there is an imminent pop, it feels more likely to be from a valuation bubble than an infrastructure bubble. Data center construction will take years and capacity can be used in ways that don’t depend on demand (model training, continuous learning) while valuations and financial performance respond much more quickly.

The playbook

Bubble or not, I believe that AI will ultimately be a generational technology—even if it takes longer than expected and doesn’t look exactly like what we’re working with today. The path might vary but the destination will be the same, so individuals and companies should take action accordingly.

Some of my personal recommendations:

For individuals

• Become extremely proficient at using AI tools, regardless of your domain—it might be more relevant than you think (Claude Code is for more than just code)

• Develop taste—for design, for software, for writing, for analysis—discerning quality of AI-generated [insert_artifact] will be a valuable skill for a long time

• Learn to learn, and learn often + diversely—learning is one of the highest leverage things you can do, and being able to learn effectively ensures you stay relevant regardless of how AI disruption shakes out

For companies

• Don’t ignore AI transformation, but start with real business problems rather than “shiny object” gen AI initiatives; there’s still a ton of uncaptured value in core data infrastructure + predictive AI

• Build a culture that’s as strongly AI-native as possible (within industry-specific compliance boundaries); Shopify is a nice north star

• Remember the bitter lesson; start simple and build solutions that scale as models improve, rather than being made obsolete by the next update