<h1>Do Not Write with an LLM</h1>
<img src="/images/green_bird.webp" alt="A photo taken by myself of a green bird.">
<h2>A Growing Trend</h2>
I have been see­ing an in­creas­ingly preva­lent trend of peo­ple show­ing up in on­line spaces proudly ﬂaunt­ing that they are writ­ing with the as­sis­tance of AI.
I of­ten see them clar­ify that they are go­ing fur­ther than let­ting the model per­form gram­mar or fact-check­ing.
They are de­scrib­ing an idea to an LLM, and giv­ing it com­plete con­trol over the ﬁ­nal writ­ten doc­u­ment.
They seem to be proud of this. They should­n’t be.
<h2>What Does Not Work</h2>
Writing seems to be a shadow of a more fun­da­men­tal and use­ful process we like to call “thinking”.
There is a rea­son why LLMs, which are the clos­est thing we cur­rently have to “software that thinks” is trained to think through writ­ing.
It seems log­i­cal, then, that we can use this “software that writes” to help along our own think­ing process, right? Wrong.
Writing is one of the most cere­bral ac­tiv­i­ties that hu­mans do on a reg­u­lar ba­sis.
<a href="https://elijahpotter.dev/articles/why-i-talk-to-myself">I try to sit down and write about a com­plex topic at least once a week.</a>
There are a num­ber of rea­sons I do that per­tain­ing to my job in par­tic­u­lar, but there are more gen­er­ally ap­plic­a­ble rea­sons that can ap­ply to any pro­fes­sion.
When a math­e­mati­cian needs to think crit­i­cally about some the­o­rem or proof, they of­ten turn to a dry-erase board or a chalk­board.
The math­e­mati­cian then writes in clear no­ta­tion what they imag­ine the prob­lem to look like in their heads.
From there, they can ma­nip­u­late that no­ta­tion un­til they reach their de­sired out­come.
The English lan­guage is ex­tremely sim­i­lar, with a key dif­fer­ence.
Math­e­mat­i­cal no­ta­tion is specif­i­cally de­signed for a nar­row do­main.
Nat­ural lan­guages, on the other hand, can be ap­plied to any ﬁeld.
By writ­ing your idea down on pa­per (or in a Google Doc, it does not mat­ter), you give it sub­stance.
This sub­stance can then be shaped it­er­a­tively to­wards a goal of some kind.
No great ideas were writ­ten down on the ﬁrst try.
They started as a vague no­tion, and through writ­ing and rewrit­ing, they be­came some­thing con­crete and valu­able.
You can­not dic­tate a vague no­ta­tion to an LLM and ex­pect it to spit out some­thing tan­gi­bly valu­able.
Any at­tempt to do so is lazy, and it will re­sult in fail­ure.
I have seen it in the wild, and frankly, it is a lit­tle em­bar­rass­ing.
<a href="https://ammil.industries/i-know-you-didnt-write-this/">This ar­ti­cle</a> feels es­pe­cially rel­e­vant to­day.
<h2>What Does Work</h2>
Using an LLM for re­search can be very ef­fec­tive.
Searches to ChatGPT or Perplexity can sur­face in­for­ma­tion faster than dig­ging around in a book you read three months ago.
For lots of searches, these two sources have com­pletely re­placed Google and DuckDuckGo for me.
They’re also quite ex­cel­lent fact-check­ers.
I’ve seen that plenty of folks have re­ceived quite good re­sults by past­ing their work into an LLM with an in­ter­net tool (like ChatGPT with Thinking en­abled).
Finally, I’ve per­son­ally found that LLMs are quite good at ﬁnd­ing places where I sim­ply for­got to in­sert con­text.
Some­times I for­get to de­ﬁne a term or in­sert a rel­e­vant link.
Even small mod­els like <code>gemma3n:e2b</code> can catch me.
<h2>What You Should Be Doing</h2>
When you need to com­mu­ni­cate an idea in your head, sit down with a notepad and a key­board and ex­plain it.
I per­son­ally think you should use a gram­mar checker, since they are far less likely to im­pede your thought process, but if you need to, you can in­struct ChatGPT to cri­tique your work once it is ﬁn­ished.
If an idea de­serves an au­di­ence, you’re ca­pa­ble of writ­ing it out your­self.
In the same vein, if you can vaguely de­scribe it to ChatGPT, you can vaguely de­scribe it to your in­tended au­di­ence.
Do your­self a fa­vor and skip the mid­dle­man.
<h2>What We Should Be Building</h2>
Now, I’d like to en­ter the sec­tion where I talk specif­i­cally about what this all means for peo­ple who cre­ate tools for writ­ers.
That in­cludes both Harper and WordPress.
A tool that helps some­one write is a tool that di­rectly in­ter­faces with how that per­son thinks.
That might in­clude what they think about, but more con­cretely I am re­fer­ring to the ac­tual day-to-day process of think­ing through com­plex ideas.
If you don’t be­lieve me, it’s prob­a­bly be­cause you skipped ahead in­stead of read­ing this post from the be­gin­ning.
Most cru­cially, we can­not al­low our­selves to build tools that dis­suade peo­ple from ex­press­ing their ideas in the way they imag­ine.
This can take the form of fric­tion, like build­ing tools that are so cum­ber­some that one dreads to open them at the start of the work­day.
This can also take the form of a tool that crushes or over­writes an au­thor’s core mes­sage.
A com­mon com­plaint I hear about Grammarly (from peo­ple who have switched to Harper from Grammarly) is that it’s too de­mand­ing. When they write prose in a cre­ative or un­usual fash­ion, their ser­vice of­ten forces them back into a colder and more for­mal way of speak­ing.
We don’t want to be like them.
For Harper, that means we need to be di­verse in our train­ing datasets and mind­ful of feed­back from our users.
For WordPress, it means we need to en­cour­age our LLM in­te­gra­tions to tread lightly and re­spect­fully.
They need to ac­cept when they’re wrong.
Just as any good hu­man should.
<blockquote>
Months af­ter writ­ing this post, I came across an­other.
Au­thor Cynthia Dunlop gives <a href="https://writethatblog.substack.com/p/dev-reaction-to-ai-blog-posts">a great overview of how de­vel­op­ers re­act to blog posts writ­ten by AI</a>.
I highly sug­gest you take a look if you have more time.
</blockquote>

I have been seeing an increasingly prevalent trend of people showing up in online spaces flaunting that they are writing with the assistance of AI. They seem to be proud of this. They shouldn't be.

I have been see­ing an in­creas­ingly preva­lent trend of peo­ple show­ing up in on­line spaces ﬂaunt­ing that they are writ­ing with the as­sis­tance of AI. They seem to be proud of this. They should­n’t be.

Do Not Write with an LLM

<h1>Local-First Software is Easier to Scale</h1>
<img src="/images/flatirons.webp" alt="The Flatirons">
The ti­tle of this post is some­what mis­lead­ing. Local-ﬁrst soft­ware rarely needs to be scaled at all.
<a href="https://writewithharper.com">Harper</a> re­cently re­ceived a mas­sive in­crease in both traf­ﬁc and user count.
How?
By mak­ing it to the front page of Hacker News.
If you could­n’t tell by the ex­tent to which I talk about this, I’m thrilled.
This amounted to a tremen­dous amount of free ad­ver­tis­ing, if noth­ing else.
I’ve been think­ing a lot about the won­drous ben­e­ﬁts of work­ing at the edge.
That’s just one term of many that peo­ple use to de­scribe Harper: “edge-ﬁrst”.
Others in­clude “local-ﬁrst” or sim­ply “on-device”.
They are all just jar­gon for a sim­ple idea: We run all the rel­e­vant gram­mar check­ing code as phys­i­cally close to the users as pos­si­ble.
That way, we can serve up sug­ges­tions faster than any­one else.
To achieve our goal, we make sure that every­thing is well-op­ti­mized and lean.
Harper barely uses any CPU or mem­ory at all.
What does all this mean in the con­text of the re­cent uptick in user ac­qui­si­tion? Imagine, for a mo­ment, we are LanguageTool.
Our soft­ware is writ­ten in Java, with ques­tion­able at­ten­dance to the ef­ﬁ­ciency of our code.
Since our soft­ware re­quires a big server to run, we have a cer­tain num­ber of servers on standby to han­dle a cer­tain amount of ex­pected load.
If sud­denly the num­ber of re­quests we re­ceived were to dou­ble (as it did for the Chrome ex­ten­sion), we would be big trou­ble.
To avoid in­creas­ing the la­tency on re­quests (or drop­ping re­quests all to­gether), we would need to scale up the num­ber of run­ning servers.
This not only takes hir­ing an ex­pert in cloud ar­chi­tec­ture, but also ad­di­tional fund­ing to pay the AWS (or what­ever) bill at the end of the month.
Because Harper runs at the edge (no server re­quired), we don’t have to worry about that.
In fact, I only no­ticed that our user count had spiked af­ter I vis­ited Hacker News the morn­ing af­ter.
No hic­cups at all.
Lots of cloud providers like to brag about be­ing able to scale with their users. I like to brag about not hav­ing to scale at all.

The title of this post is somewhat misleading. Local-first software rarely needs to be scaled at all.

The ti­tle of this post is some­what mis­lead­ing. Local-ﬁrst soft­ware rarely needs to be scaled at all.

Local-First Software Is Easier to Scale

<h1>Slop Paralysis</h1>
<blockquote>
slop paral­y­sis - noun
A com­plete or par­tial loss of func­tion while re­view­ing the out­put of a cod­ing agent.
</blockquote>
Let me paint you a pic­ture.
You have an idea for prod­uct.
It could be any­thing: A mo­bile app, a dash­board, or a script to au­to­mate your work.
So, you sit down with your fa­vorite LLM and de­scribe your idea.
Maybe you have a pretty good un­der­stand­ing of how it should be im­ple­mented.
You might even know the over­all struc­ture of the pro­ject in your mind.
You tell your cod­ing agent all of this.
Then, you let it loose.
It cooks and cleans and im­ple­ments your prod­uct for you.
In the end, you have some idea of how the end re­sult works, but it is not com­plete.
Since this is a pro­ject that is im­por­tant, which you in­tend to main­tain, you go to read the code.
That’s when it hits you.
Slop paral­y­sis.
<h2>The Problem</h2>
Slop paral­y­sis is the com­plete lack of de­sire to re­view the out­put of an LLM.
It could show up for any num­ber of rea­sons.
The most com­mon, for me, are:
<ul>
<li>The sheer amount of code de­mand­ing con­sump­tion.</li>
<li>Missing con­text (that the agent was aware of, but not you).</li>
<li>A fear of break­ing some­thing.</li>
</ul>
In the end, slop paral­y­sis slows you down and makes your life more stress­ful.
So, what can we do about it?
<h2>Some Solutions</h2>
I will de­scribe some so­lu­tions that have worked for me.
As al­ways, your mileage may vary.
The ob­vi­ous so­lu­tion is to sim­ply not use an agent.
Some­times cod­ing agents make your job eas­ier.
Some­times they do not.
<a href="./when_to_use_an_agent">Knowing which is which is dif­ﬁ­cult, but ex­tremely valu­able.</a>
When you do de­cide to use an agent, you can have the agent sim­ply pro­duce less code.
I have heard of <a href="https://github.com/DietrichGebert/ponytail">pro­jects</a> that help you do this, but I have not ac­tu­ally tried them.
In­stead, I ask the agent to make a plan ﬁrst, then re­work that plan my­self to min­i­mize the num­ber of changes.
In the end, a plan which was orig­i­nally writ­ten by the agent be­comes one that has been mer­ci­lessly edited by my­self.
In this way, I min­i­mize the amount of code which de­mands con­sump­tion.
The side-ef­fect of this is that I then have an ex­cel­lent un­der­stand­ing of what the agent ac­tu­ally does, which helps with the con­text prob­lem.
The ﬁ­nal strat­egy, which I use when all else fails, is to refac­tor the code by hand.
When the agent has proven the tech­ni­cal fea­si­bil­ity of the pro­ject, but the code is sim­ply too ex­pan­sive to prop­erly grok all at once, I sit down with a ﬁne-tooth comb and refac­tor it, mod­ule by mod­ule.
I do not need to care­fully read each func­tion and eval­u­ate its mer­its, but I do force my­self to, at min­i­mum, lay eyes on them all.
<h2>Stay Steady Out There</h2>
I ﬁnd my­self be­com­ing more over­whelmed by the dis­course every sin­gle day.
It’s ex­haust­ing how much is hap­pen­ing in the world, and even worst, how much you are ex­pected to care about it all.
Take some time for your­self.
Save your­self from slop paral­y­sis.

A complete or partial loss of function while reviewing the output of a coding agent.

A com­plete or par­tial loss of func­tion while re­view­ing the out­put of a cod­ing agent.

Slop Paralysis

<h1>Stacking PRs</h1>
I tried out GitHub’s PR stack­ing func­tion­al­ity for the ﬁrst time this week.
I have to say — it’s amaz­ing.
Instead of im­ple­ment­ing the en­tirety of <a href="./harper_for_windows">Harper Desktop’s Windows</a> sup­port in a sin­gle mas­sive PR (as I tend to do far too of­ten), I de­cided to sep­a­rate the work out into in­di­vid­ual PRs and stack them.
I am some­one who goes on a lot of tan­gents while work­ing.
While writ­ing a new mod­ule or crate, I of­ten ﬁnd my­self dis­cov­er­ing prob­lems with my pre­vi­ous work.
To get the new mod­ule to a place I am sat­is­ﬁed with, I will need to go back and make changes to some­thing seem­ingly un­re­lated in or­der to keep up a high bar of qual­ity.
Stacked PRs make this or­ga­ni­za­tion­ally pos­si­ble.
I can make my tan­gen­tial changes as a part of a sec­ond PR, ei­ther be­fore or af­ter the cur­rent one in the stack.
It’s re­ally nice, I sug­gest you give it a whirl.
Plus, the TUI for it is pretty slick.

I tried out GitHub's PR stacking functionality for the first time. It's amazing.

I tried out GitHub’s PR stack­ing func­tion­al­ity for the ﬁrst time. It’s amaz­ing.

Elijah Potter

Stacking PRs

Comments

Other Stuff

Do Not Write with an LLM

Local-First Software Is Easier to Scale

Slop Paralysis