This article of about 2500 words was almost entirely generated by a large language model. I did make some edits before it was published, but this is the full diff of what was changed:

LLMs have become an indispensable part of my writing pipeline, and I think a lot of the techniques I use to write are still relatively uncommon. In the spirit of learning together, here's a short demonstration of how it was made, prompts and all.

§Step 1: Surface area

The first thing I always do is to write an outline. Usually for me that's in the form of an argument. What is the central core of what I want to express? Don't think too much about language, just get things out and onto paper. Here's the outline that became the article:

ARTICLE_OUTLINE:
"""
Title: Why Large Language Models will disrupt the way shipping works today

The argument:

* Maritime has large amounts of unstructured data, similar to other industries like insurance
* Need for digitization has increased over the past decade, with more and more of this data being exchanged as the industry decentralizes. Ships can change cargo within days, new suppliers pop up all the time, and compliance requirements increase the number of reports being stored and assessed, constantly.
* Having this data be unstructured has meant large amounts of human time going to waste simply accessing and reading this information. chances of mistakes are massive, no real analytics or knowledge of history, and
* Despite this, the only way to digitize until now has been to switch to forms and other methods of data entry - which work in very small tightly controlled groups, but have proved impossible for an industry this large.
* The problem isn't getting from 90-100, it's getting from 0-5. At anything less than 50% penetration, everyone involved has to use both systems - unstructured text like Email and pdf reports, AND whatever the new system is. It's unreasonable to work this way, and the increased cost of operation isn't worth it.
* The missing piece has been the ability to parse complex unstructured human language without humans in the loop.
"""

This is a good exercise regardless of your process. Lay things out in simple terms. Connect your sentences together, and it helps you figure out if what you have to say is worth saying.

From a language model perspective, this skeleton is going to help the model understand the flow of what you're trying to write. It's missing all of the meat - the examples and elaboration - but it has the core along with some surface area to grab onto.

Here is also where I add in sentences that I think are interesting, or have been knocking around my head. It can't just be me - sometimes you have good sentences or thoughts that come around without premise or conclusion, you just know you want them to be part of your piece. If you have motifs, quotes or other segments, this is a good place to add them.

Spend a little time here until it makes sense to you, ideally at least until it will make sense to someone who is intimate with the subject matter.

§Step 2: Collaborative expansion

The next part of the process came from looking at how I write with people I respect. I don't narrate twenty paragraphs to someone, I start with a skeleton and wait for them to ask questions. We discuss what is missing and unclear, and the piece forms from our conversation.

Doing exactly that would be another wonderful way to start. About half the time, I'll discuss the matter with a friend and pull out a transcript with whisper. This transcript can be a ready substitute for the skeleton.

Once we have it, the next step is to have the model assume a personality - in our case, a reader in maritime - and ask questions about what might be unclear or confusing. The prompt:

ARTICLE_OUTLINE:
"""
<skeleton goes here>
"""

ARTICLE_OUTLINE contains an article I'm writing for a maritime audience. We want to improve it. First, I want you to read this from a maritime reader's perspective and ask me questions about what might not be clear, and what can be confusing.

Even using Mistral-7b, a tiny local model, this yields a good number of useful questions. In my case, GPT-4 was quite helpful:

1. How will switching to a more digitized system reduce human error or improve operations? It might be useful to provide some quantitative examples or case studies to underscore your argument.

2. What do you mean by "The problem isn't getting from 90-100, it's getting from 0-5."? This might be a bit confusing to some readers.

3. Can you provide a real-world example showing how LLMs have been used in other industries, and highlight the sort of improvement or change they have brought about?

4. What are PDAs and FDAs in the context of maritime operations? Not everyone might be familiar with these abbreviations.

5. What challenges might organizations face when implementing this technology? Implementing a new system could raise concerns about cost, time, and disruption to current operations. Addressing these concerns might make your argument more persuasive.

6. Will adopting these technologies require a significant investment in employee training? If so, how will the benefits outweigh the costs?

7. When you discuss making all information accessible "as though it were sitting in a single Excel sheet," do you mean the technology groups and organizes data effectively, or does it also provide analysis or insights? If so, how?

It's useful to switch models a little bit, and keep answering and asking for more questions until the model is either satisfied or becomes repetitive. I find it easier to turn on voice recording and ramble the answers out, going on tangents as they come up:

If you can (and it's why I'm using playground instead of ChatGPT), it's useful to edit questions and delete ones you think aren't relevant. The cleaner your conversation history is, the better your results will be.

Once you have enough questions and answers, you should have the meat of your piece along with the skeleton.

§Step 3: Reorganize and structure

Clean up the history - and make sure we didn't miss anything, with this prompt:

Can you outline all the answers and the questions they answer for me, to prepare them for addition to the article? Don't leave anything important out.

Depending on your LLM, it might be useful to use self-reflexion and ask anything else we missed? to make sure we're being exhaustive.

At this point you can ask for a revised outline. I find it helpful to reiterate the topic statement just to keep things in order:

Once we have an outline, we can start expanding it further. The mistake I see often made is to ask for the whole thing all at once, or to expand too much too fast. LLMs like to be brief - a side-effect of RLHF, seeing how some finetunes evade this problem - so it helps to chunk the output. I find that it helps to start by asking to expand each section (you can automate this process), with this prompt:

Can you write section one in detail, in the form of bullet point sentences? Don't leave anything out. Not an outline, the actual content with facts and information.

Once you have all the sections expanded, you can inspect and edit to make sure what you have is what you want to say.

§Step 4: The opening

As with any writing, the first sentence is the most important one. The first paragraph is the second most important, the first section the third most important, and so on. You want to spend some time on the first line - ideally it's something you come up with yourself, but you can get some help.

The best method I've found is to try different models. Use the same conversation history to have them generated multiple versions of an opening paragraph. Often there's a version of what you're looking for in there. Providing an example paragraph can help guide the style, perhaps from your own writing. Here's the prompt I used for the article:

What I need now is a good opening section that outlines the key argument, problem, why a solution has been impossible, what that solution now is, and how Greywing is part of it. A good opening section should get right to the point, hook readers, be interesting, and outline the key points of the article. Two paragraphs at most.

Here's an example of one of my own openings:
"""
Security and convenience are at opposite ends of the same spectrum. It's easier not to lock your door when you leave your house - no key to lose, no lock to malfunction between you and your home. Humans are strange. Combine the fact that we hate inconvenience with a passion, and that we find it quite hard to fold in large, uneventful eventualities - something I know dearly from my time in insurance - and we have a recipe for an insecure world at large. Cue post-it notes with passwords stuck to monitors and deliberate backdoors built into secure systems for forgetful users. It's inconvenient to be secure.
"""

Make it easy to understand, using simple sentences that aren't too flowery in the first person as the CTO of Greywing. Very simple english when possible, easy to read. Short, clear sentences. Give me five versions of an opening paragraph.

In my experience, Claude was better - I feel my preferred dialect of English lines up better with Anthropic's tuning. Once you've found the pieces, I strongly recommend writing the first paragraph in your own words.

Once you have a good opening paragraph, you're off to the final step.

§Step 5: Write the thing

The key here is to take the information you've massaged together along with the outline, and expand it out to a piece in your own voice. Depending on how happy you are with the expanded outline, you can do one of two things here.

The first - and what I went with in this case - is to copy over the outline to a fresh conversation. Segment it out, and copy in the opening paragraph to another segment, and use this prompt to write out the full piece:

OUTLINE:
"""
<expanded outline goes here>
"""

OPENING_PARAGRAPH:
"""
<custom opening paragraph/section goes here>
"""

OUTLINE contains the initial skeleton I wrote for an article, as the CTO of Greywing. OPENING_PARAGRAPH is the first and most important paragraph I've written. Help me write the rest of the article.

Here's a set of section titles:

1. Intro (no title)

2. When more communication is too much communication (outlining the problem in detail, with examples)

3. Why past attempts have failed (some examples and reasons why it was missing the critical piece)

4. Large language models (what they are, what they are good at, and how Greywing plans to use them)

5. Implementing the Solution - No Disruption, Gradual Adoption

6. Early adopters get the worm

7. What we get for free (other benefits like multimodal and multilingual)

8. What the future holds

9. Conclusion and call to action

Now help me write the full article. Start with my intro paragraph verbatim, then add each section in detail. Style should be mine, in active voice first person, simple easy to understand sentences, nothing too flowery. Explain what might be confusing to a maritime reader in detail.

There are two things happening in the prompt above:

1. We use our own section titles as a way to guide style and content. All LLMs I tried intuitively understood parentheticals as instruction and the rest as actual titles.
2. Forcing the model to begin by reiterating the first part (written by you) forces style better than other methods I've tried. LLMs are rarely good at copying text, so you might want to copy your intro back in to the final piece, but this reinforces (perhaps in token probabilities) your manner of speaking and your voice.

If you're using Claude (or another LLM used to outputting long text), or you have a short piece, you can do all of it in a single shot. Otherwise, you might need to ask for each section one by one.

§Why write this way?

In this case, my input to the model totaled about 3000 words. The finished article was about 2500, which raises the question.

To me, it's all about which way helps you write more, and write better. Here are a few ways this is significantly better for me:

• I find it easier to answer questions and ramble on, instead of facing an empty page with something to say.
• The back-and-forth always reveals something that I took for granted because of familiarity, or points out something that I hadn't considered - either as a point or counterpoint.
• I find this approach to writing more steerable. If I get feedback (or a thought) later in the writing process, it can usually be hard to incorporate it into the piece without breaking or doing a complete rework. With this method, I can go back far enough into the formative process, update and rerun to get something that needs a lot less editing.

Honestly, I write easier when I write this way. Even though there are times I've decided to write something entirely myself, time spent on this process has always been worth it.

Either way, I hope that helps. The article you're reading now has had no AI input - so forgive me, and do point it out if anything's unclear!