In my previous post, I gave a few glimpses of what I'm building, which is at its core an integrated platform for knowledge work (including coding) on MacBooks. That innocent-looking parenthetical has a very interesting consequence: since coding such a platform is knowledge work, at some point I should be able to use Air Gap to build Air Gap.

In fact, that has already happened: I'm now fully self-hosted, which means I no longer rely on cloud LLMs (until recently, Gemini) to help me do my work. I'm currently editing this very blog post with the assistance of my own prototype.

Much has been written on the pros and cons of eating your own dog food, and I have nothing to add that you haven't heard before. What I can provide insight into is how to use LLMs for knowledge work. I see lots of people using LLMs the wrong way, so I'll start with what doesn't work.

Don't Let Them Write Prose

Prose written by LLMs is insufferable. There are only so many "quietly", "load-bearing", and "it's not X, it's Y" that your reader can take before they're morally justified in punching you in the face. If LLM-written prose sounds just fine to you, go read more books.

I'm not merely making a style argument: good writing is a consequence of good thinking. If your prose shows no sign of writing effort, then no thinking has happened, so I can safely disregard your opinion: it's either completely obvious or utterly insane.

Still, earlier I mentioned that an LLM is assisting with this post. LLMs are great at all the drudgery that gets in the way of good writing: grammar fixes, style checking, and "please replace all inline links with footnotes."

Don't Set Up Multi-Agent Systems

Twitter is full of bozos who argue that if you're not following the buzzword du jour (loop engineering / graph engineering / ...), you're hopelessly falling behind and destined for the permanent underclass. Ignore them. They had no track record before, and they're shipping nothing of value now.

Clankers are not people, so telling a clanker to act as a QA tester doesn't make it so. Even if they were people, you still shouldn't command and control them, locking them into fixed communication structures.

For now, all you need to be productive is an extensible harness with which you can nudge and cajole a model toward your goal. I like Pi; maybe one day I'll try DeepSeek Harness. Both were built by excellent engineers who know what they're doing and generously share what they've learned.

Do You Have a Spec?

It's no coincidence that this section shares a title with step 7 from the Joel Test: writing a spec was a good idea then, and it still is. If you only have a vague idea of what your software is supposed to do, it's unlikely to do it well.

Ultimately we're supposed to write software to solve a problem people have. It follows that you should be able to write down what the problem is and who needs it solved. Invariably those people face some constraint that makes the obvious solution impractical; write that down, think really hard, and then write down how to navigate around this new issue. Keep doing this work, which is what you ought to be doing anyway, and there's your spec.

Now imagine you've written this very detailed spec. You hand it over to your favorite development team, and you get back an implementation that, from what you can test, seems to comply with your spec. Would you feel comfortable shipping it without having read all of its code? You should, because that's the same situation in which countless program managers have found themselves over the years, and nothing bad seems to have happened. So having a spec is not only necessary, but it will also save you the time you'd otherwise spend reviewing the coding output of your LLM line by line.

Agents Thrive on Feedback

Creation: Life and How to Make It deserves to be better known, because it contains many pointed observations on what makes a system truly intelligent. In particular, the author, Steve Grand, argues that feedback from the environment is a fundamental ingredient of intelligent systems:

Adaptation is also a feedback process. Changes in the environment feed back on the organism through its senses and cause changes in its behaviour. When a creature walks into a rock, the feedback from its senses cause[s] it to alter its behaviour and stop or turn.

Primitive forms of learning become possible when the feedback is not directly coupled to the creature's behaviour but instead is applied to some kind of memory of the event, so that instead of reacting now, after the fact, the creature modifies its future behaviour. Such a mechanism is a simple form of prediction, because it is predicting (on the basis of a past experience) that in situation A action B will be a good response. Since it is a form of prediction, it is also a primitive form of intelligence.

This 25-year-old argument closely matches my experience today: LLMs become a lot more useful when they are granted the ability to measure the effect of their actions. Once the spec becomes something executable that the LLM can compare against on its own, the loop is closed, and the output improves a ton.

For a silly but concrete example, I wrote in my spec that I wanted this blog to have nice-looking typography, in particular avoiding orphans, runts, and widows: in short, dangling text that ruins the vertical rhythm of the whitespace (and yes, I'm that picky.) A text-only LLM can't reason about the visual properties of a piece of text: they depend on choices made by the layout engine of a browser. However, when you let your LLM jury-rig a tiny HTML view that counts the number of lines of text in each paragraph, it suddenly can.