Notes on Writing With AI

Where should we use LLMs as compressors, and where as decompressors?

I’ve always found writing to be challenging. I often get really hung up on the minutiae of how to word things, and occasionally crash out over silly stuff. There is no single English word for “increasing in frequency over time”, which I find infuriating as someone who studies the flooding that follows rising sea levels. I can be a bit of a perfectionist, and in a high-dimensional medium like prose, the hunt for the best possible next move can never really end.

Part of the problem is that writing effectively requires you to have a good model of both your reader and of your subject matter, and the two are hard to connect when feedback is scarce. For me, AI has been a revelation here. Working with a large language model (LLM), I have access to effectively infinite rapid feedback from the world’s smartest, fastest-thinking, and most patient guy.

There are folks out there pushing for a sort of luddism around writing. In academic circles, you’ll hear opinions across a spectrum that runs from “annoyed about reading so much AI writing” to “concerned about student development”. Both ends are reasonable. If I spend all morning prompting coding agents, the last thing I want to do at 4pm is read and grade 50 LLM-generated takes on the same discussion post, and I don’t think the students get much out of that either.

But I don’t think AI abstinence is the answer. Luddism only makes sense if our goal is to keep practicing the extant rituals and traditions of learning. If our goal is truly to learn and communicate most effectively, we need to figure out how to work with these new creatures as they grow. There are new best practices to discover.

LLMs are too fast of a moving target to figure out best practices once and etch them in stone. But they’ve been capable enough to be useful for quite some time now. Mostly through trial and (a whole lot of) error, I’ve developed a framework for evaluating my own AI use in writing, plus a handful of practices that serve it well. I’m sharing these ideas in their current form below. I’d love to hear about the practices you use in your own writing or teaching, and to get some feedback on mine.

Here’s the main thing to ask yourself: Where are you using the LLM as a compressor, and where as a decompressor?

For anyone that isn’t a big nerd about compression like me, let me explain. Think about a big file on your computer that takes up a lot of gigabytes. You can zip that bad boy and make it smaller. How? The computer will look at every 0 and 1 that makes up the file, identify redundant or repetitive stretches, and figure out a shorter way to express the same information. That’s compression.

Now think about unzipping the file. The decompressor knows the patterns the compressor used, so it can take those shorter descriptions and expand them back out. Your tiny file is lengthy again. That’s decompression.

There’s a way to use LLMs as universal decompressors, and it could reasonably be called lazy. You can enter a brief prompt, like “Write a four-page essay about the Iliad”, and watch it expand from your micro-prompt into an actual four-page essay about the Iliad. The LLM has learned the entire world’s worth of patterns, so it’s happy to fill in the gaps for you, even if the gap is the entire essay.

This is, of course, one of the habits that people are frustrated about. Your readers have access to the same LLM that you do. Anyone could’ve typed that in and gotten a comparable essay. The shortest, most effective, most compressed description of your essay is “ask an AI this” + your prompt, which didn’t have much going for it in the first place.

There’s also a way to work with LLMs to compress your understanding. Imagine you start with an incomplete, half-formed idea and work iteratively with a language model to challenge and refine it. Maybe you go down some fruitless, dead-end roads, and at times you end up more confused than when you started. But if you emerge with an improved understanding and can communicate it effectively in writing, your readers don’t have to wander down those same roads. That’s compression!

Your writing should be a compression of your learning process with AI. And when the piece is for other humans, it’s a nice convention to hand-make it, as a signal of care and intent.

So here’s the test: which is a better description of what you’re trying to say, your piece or your prompts? If it’s your prompts, what’s the point of the piece? You might as well just hand in your prompt.

Decompression has its place too, just usually not in your prose. LLMs make great decompressors for turning descriptions into visualizations, handling the tedious parts of writing like citations and half-remembered references, and digging up evidence to honestly test your claims.

My rule of thumb for writing with AI is simple: compress your learning, decompress the labor. I’ve organized the practices below into three groups: staying the compressor, writing for your reader instead of the model, and decompressing the labor.

I. Stay the compressor

Separate your brainstorm from your draft from your revisions

If one document or AI chat contains your whole process and product end-to-end, the LLM’s speed becomes a liability. It can work much, much faster than you and is trained hard towards getting things done, so it may advance your product faster than you can advance your understanding.

So I’ve started separating my writing process into more distinct steps, which requires me to be the sole vessel that carries context between them.

This is the opposite of the advice you’d hear for getting most tasks done with an LLM agent, like fixing a bug in a codebase or solving a math problem. When the LLM is the one executing the work, it gets better the more context you give it: more published papers in that subject area, more bug reports, and so on.

But if you let the LLM carry the context of your writing, you never have to synthesize the ideas yourself, and you’ll almost certainly end up with an LLM-decompressed product.

I usually start with a Google Doc or an LLM chat on the web, depending on how developed my idea is, and jump between them in a loop until I’ve developed a 100% human-written first draft. The LLM doesn’t get to see the draft until it’s done, but I’ll talk through my ideas in chunks as I work them out.

From there, I work alongside the LLM to find opportunities to edit and improve my rough draft. For that step, I actually like to use an LLM agent harness on my laptop instead of the web chat. More on that later.

It’s easier to be a critic

LLMs have made the biggest difference for me in the revision phase. I used to agonize for hours, days, weeks about tiny things that don’t matter. For whatever reason, I find it a lot easier (and more bounded, I suppose?) to ask the LLM to suggest revisions to a weak passage, then critique its suggestions myself.

Sometimes LLMs suggest good, clean, minor edits and I accept them. Usually these include things like grammar corrections, simplifying my phrasing, or reordering my ideas.

Most of the time, though, the suggestions either A) aren’t quite what I want to say or B) reveal some inconsistency or ambiguity in my existing text and thought process. For me, seeing it done wrong makes a lightbulb go off. If I can explain exactly why the suggestion is wrong, I must know the right thing to say. As a critic, I can iterate on my writing without all the open-ended wallowing.

And in turn, by offering precise critiques of the revisions, you point the LLM closer to your true intent and build a shared understanding. This makes the LLM better at evaluating the rest of your draft. It’s a great funnel!

Let it coach you, but don’t write to please it

If you’re a perfect writer, congrats, nice work. Please send me some perfect writing. If you aren’t, LLMs are tireless coaches that can detect good and bad patterns in your writing and bring them to your attention.

If you know specific things you struggle with, you can let the LLM know up front what you’d like to aim for or avoid. This can get sticky if you aren’t careful, though. The LLM has incredible general knowledge, but its perception of quality may not align with yours or your audience’s. Part of that is likely downstream of how they’re trained on coding and math problems: these things will tirelessly drill down towards highly precise, often self-imposed goals that might not serve your writing or your audience well. That shows up in two common failure modes:

  1. They take things very literally. If you say something highly constraining, like “never let me do x” or “this absolutely needs to be like y”, even a smart LLM will go to great lengths to contort the work to meet those goals verbatim. Try using softer language, or better yet, provide the LLM some writing samples and have a more open discussion with it about how to improve your writing and what to aim for in the context of your goals.
  2. They try too hard to give balanced feedback. Anecdotally, this feels like an overcorrection from the previous crop of models that were quite sycophantic. Anything you said to a model last year was the greatest thing ever. Anything you say to a model this year is somewhat good but has some caveats, regardless of what it is.

Put those together and you get the trap I fell into a few times. If you try to satisfy every criticism the LLM raises, you’ll end up writing something a bit tortured, and it’ll drift further and further from sounding like a human wrote it. Don’t iterate on something with an LLM until it says it’s perfect. I’ve produced subpar, overly-LLM’d writing at times as a result. It’s up to you to be the ultimate judge of quality.

Check yourself with Pangram

Pangram is perhaps the only decent AI writing detector. I promise I’m not getting paid by Pangram, I just like using it.

If you run Pangram on your own writing, it’s a really nice measure of whether you’ve ceded too much control to the LLM. Chunks of text that read as AI will light up red, and you can go back to the drawing board in those places.

This is also a potential surface for abuse: in theory a student could rearrange word choices or something until it passes Pangram, hacking their way around the detector. This doesn’t help anyone. But for a disciplined writer iterating on their work with AI, it’s an effective litmus test.

Personally, I like to see that my complete first draft and my complete revised draft get 100% human on Pangram. If I have to crunch it down to hit a word count, I’m ok with seeing something like 10-20% AI, as long as it was compressed from something 100% human, isn’t annoying to read, and stays true to my intent. I was never fond of the word count hacksaw process anyway.

It’s also a lot of fun to run random emails and text from the internet through Pangram. You might be surprised at just how much stuff is fully AI generated!

II. Write for your reader, not the model

Watch out for your shared vocabulary

Remember that shared understanding you build by critiquing the LLM’s revisions? It cuts both ways. If you have a long, ongoing conversation with a model, you’re building a unique, shared context. You might notice that the language and framing it chooses to describe something is internal to the conversation you’re having with it, and might not make sense to someone else.

This is a problem when you’re condensing something down or trying to hit a word count. The LLM will make cuts that are appropriate for your shared vocabulary, not for an outside reader. Make sure you’re carefully evaluating the writing outputs from an outside perspective, not an inside one!

Borrow your reader’s eyes

You can work with the LLM to get that outside perspective. The LLM is a different kind of being than you’re used to talking to, and it can evaluate your writing from a uniquely broad point of view. Its own read on your work is worth hearing on its own terms. Within that breadth, it also knows a bit about what it’s like to be your advisor, your committee, or your worst enemy, and you can ask it to read your work through their eyes. It won’t always take the reader’s point of view on its own, so ask!

One pattern that I like using is to turn off my web chat memory, go in incognito mode, sign out, or otherwise obscure my own identity from the LLM. Then I’ll use a prompt something like:

I work at [organization] and I’m evaluating applications for [solicitation]. See the link here for more information: cool-org.com/solicitation. We just received this application for it: [cv.pdf, writing.pdf]. What do you think about this application, given the solicitation? What would you do with this application?

The feedback you’ll receive is often very different from the feedback you’ll get if it knows you’re the author! Again, don’t try to follow all of it. But it does help surface more perspectives for you to consider.

I ran this post through an incognito chat for an outside read. It still figured out who I was:

One amusing note: he recommends going incognito and asking the model for an outside read, and this is an incognito chat. If you’re Riley, then per your own advice, don’t try to fix all of this; take what rings true. (And yes, that applies to my somewhat balanced feedback too.)

Make it fun to read

Effective writing captures both information and the attention required to deliver it. If your writing is more fun to read than LLM outputs, you’ve found an edge and made a meaningful original contribution.

LLMs predict the next most likely word (with some caveats), and can produce certain repetitive patterns. Humans enjoy a little rhythm and surprise. If you use LLMs too extensively, your writing gets pulled towards formality and mechanics. If you notice your writing doesn’t sound like you, it’s time to dial the LLM use back.

Sometimes your reader is an LLM

On the topic of attention, LLMs have oodles more of it than humans. Sometimes it’s genuinely useful to write something meandering and ugly that a human might not enjoy reading, just to get it down on the page so an LLM can reference it later.

I use this strategy a lot, especially for internal and technical stuff that I don’t really intend for other humans to read. It’s very convenient to fire up a new LLM agent chat and say something like “Ok, go read Documents/notes/crazy_idea.md, /big_picture.html, /stuff_that_I_already_tried_and_didnt_work_well.txt and then read and implement Documents/projects/new_thing_to_try.txt”.

Writing some slop, whether it’s organic, farm-raised human slop or AI-assisted slop, is not necessarily a sin to be avoided at all costs. You just need to consider the venue, and human venues usually aren’t as happy to receive slop as LLMs are.

Code documentation is an interesting battleground for this. I rarely write or read code by hand these days. I’m not particularly interested in handwriting its documentation either: code isn’t really of, by, and for humans anymore. But if you click onto someone’s GitHub project (including any of mine!), the README files that serve as the front cover are usually LLM-generated disasters. I think the medium-term move will probably be a human-facing post about the intent and features of your project, linked at the top of your README. In the longer term, I’m not sure what kind of contact we’ll have with code, if any. ¯\_(ツ)_/¯

III. Decompress the labor

Use more than just words

Writing is just one mode of communication. You can more effectively capture a reader’s attention and get an idea across when your writing works in concert with other forms of media.

LLMs have nuked the time costs and skill barriers previously associated with creating neat little visualizations and interactive widgets. Let’s work through an example.

Did you know flood frequency can speed up even when sea level rises at a steady pace? No, you didn’t? Let’s learn interactively.

Here’s the real tide at Wachapreague, Virginia, in 1985. On average, there are 1.93 high tides a day here. Hit record to catch each day’s highest one.

An animated tide gauge trace at Wachapreague, Virginia, in 1985. The water rises and falls about twice a day, and each day's highest water drops into a histogram. A full year of daily highs makes a bell-shaped spread from about −60 to +60 cm relative to mean higher high water, centered near −5 cm.

Loading tide data…

Every year has its own spread of daily highs, and the whole spread climbs over time. That’s sea level rise! It’s not just one number going up. Rather, it’s the whole distribution.

Histograms of daily high water at Wachapreague, each pooling five years, with a slider that steps through the record from 1979 to 2025. The whole spread moves upward over time. The median daily high rises from about −5 cm around 1981 to about +16 cm around 2023, and the middle 80% moves from −30 to +20 cm up to −9 to +42 cm.

Loading tide data…

Now pick a fixed elevation. Maybe this represents a road, a house, a farm, or an ecosystem. Let’s count the number of days that elevation goes underwater, and how it changes as the distribution of sea levels moves higher.

The same histograms with a draggable elevation line, set at NOAA's minor flood threshold of +55 cm, above a bar chart of how many days a year the daily high tops that line. At +55 cm, the count goes from about 1.9 days a year in 1979–1983 to about 14 days a year in 2021–2025, roughly 7.6 times as often, while the spread itself rose at a steady 5 cm per decade. A blue curve from a bell-shaped model with a steady rise bends upward the same way. Years with too little data (2000 and 2006–2008) are hatched.

Loading tide data…
Daily high water at Wachapreague, Virginia. Hourly water levels from NOAA tide gauge 8631044, relative to mean higher high water (the average daily high tide over 1983–2001). Histograms pool five years of daily highs. The blue curve assumes a bell-shaped spread of daily highs that rises at a steady rate. Inspired by Figures 1.3 and 3.1 in Sweet et al. (2022).

Isn’t that easier to understand than if I had told you something like this without the visualization?

Imagine a Gaussian distribution shifting higher. Now imagine a fixed threshold on the same axis, deep in the right tail of the distribution. As you shift the distribution higher, a progressively fatter part of the distribution crosses the threshold. So the proportion of the distribution above the threshold speeds up, even though the shift is steady.

Here’s the prompt that got this made:

My original prompt

wanna do the widget now? my inspiration is sweet et al 2022 figures 1.3 and 3.1, which you can find in my zotero. its the usgs report about sea level rise scenarios. I think the steps we need to get across to the reader are something like: 1.) sea level isn't just one number. tidal variation makes it a distribution. i think it would be cool to have a live viz of a tide going in and out, and you can hit a button to start recording data on it, and watch it fill up a histogram. 2.) that distribution shifts higher over time. maybe we have a slider to do years and collect data on them? or a shortcut button to collect all the data? or just a few tabs with 1 per decade? what do you think would work best? i'm kinda feeling slider, but if it's better to use less or synthetic data figure out the best way to do it. we should use real data for this if possible but i don't know how big the files are / if they're appropriate for my website. there's a tidal data folder somewhere under Documents/dev/ or maybe Documents/dev/try if you can find it. 3. pick a fixed elevation and see what proportion of time it's under water or its annual flood frequency. follow that over time as the water comes up. see the histogram passing you by and getting thicker. thoughts on how to set this up? I want this to be simple, intuitive, and beautiful, with maybe just a dash of minimal guiding text.

From this one crude prompt, Claude Opus 5.5 built a fully working and correct version of the interactive visualization you see above, and I followed up with maybe 30–45 minutes iterating on the design with Claude.

This is decompression, but of an idea I’d already compressed, aimed at your attention and understanding.

Unfortunately, widgets like this aren’t always a great fit for the PDF-forward world that we live in, where interactivity is limited. Even within the shackles of the PDF, LLMs are great at turning little hand-drawn doodles or written descriptions into nice-looking visualizations.

Put the LLM in a position to succeed

Sometimes, especially around academia, you’ll still hear whispers of long-gone 2023-era LLM concerns. We’ve come a long way since then.

The models are extremely good! They’re frankly better and faster than humans in most well-defined, closed-form tasks. However, they are only trustworthy at doing those things if they are put in a position to succeed. What does that mean?

LLMs need access to tools to verify their work. That way, if they make a mistake, they can check it, and go back and fix it. This sort of iterative workflow has enabled a massive expansion in capabilities. Here are a few examples:

  1. Have an LLM doing a calculation? Ask it to use Python. They’re pretty good at mental math now, but it’s just safer to use Python.
  2. Formatting a citation? Don’t just ask for it. Instead, give it access to your citation manager (like Zotero) via the command line, and it will give you beautiful and perfect citations.
  3. Asking it to find something for you? Make sure it has access to the internet and search tools.

These things all come standard in an agent harness: a program on your computer that keeps track of your conversation and allows an LLM agent to perform tool calls, like searching the web and running code. This is part of why I like doing revisions with the agent instead of in the chat. When an agent has a good toolkit, it can check its own work, and becomes way less likely to shoot itself (or you) in the foot.

LLM agent harnesses have existed for a couple years and have been excellent for about a year now. If you don’t have one yet, download one now, this is your sign! The longer you take to update your workflows, the more opportunity you’re leaving on the table. I promise the learning curve is very small relative to the payoff, especially when you can just ask the agent for help working with the agent.

None of this has anything to do with your communication or intent. This is just labor, and we can work with LLMs to get it done better and faster than we could before.

Ask it for the world

The personal website has never been more back. You can get a free URL from GitHub Pages or pay a few bucks for a custom one from Cloudflare, which has nice tools for letting an agent deploy your site. Ask an LLM agent to help you customize a site and deploy it. Even if you don’t know how to do that, the LLM does! Don’t be afraid to ask it for the world. These guys are really capable now, they want to help you, and you can materially raise your ambition as a result.

And don’t stop at websites. I’ll often ask an agent something like:

Spin up a ton of subagents, go find and read every single published paper on this topic, aggregate what you find, evaluate the entire history of thought, and pinpoint exactly where this idea originated. Save everything you find so we can run new queries against this corpus later.

It doesn’t always pan out (we need to kill closed-access journals once and for all), but when it does, I learn in an afternoon what would’ve taken me months of digging.

If you think your learning and writing would be well-served by a venue that doesn’t exist yet, or would work better if it were backed by something laborious to produce, don’t let that stop you. Try crazy stuff!


All of this might sound more complicated than just opening a Google Doc and letting it rip. If you haven’t given the latest round of LLMs an earnest shot, I urge you to do so. They are incredibly smart, and they’re smart in a different way than a smart human is smart. This is a world-changing technology that can help you learn more efficiently and challenge you more than ever before. Learn to pilot the rocket ship!

Remember: compress your learning, decompress the labor.

Thanks for reading, big dawg. Let me know what you think.

Comments

Loading comments...