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