The next thing a writer builds might not be an article

A copywriter wrote on LinkedIn this week that more writers should start building digital products.

One line caught my attention: English is becoming a kind of programming language. If you can explain clearly what you want a system to do, an LLM can help you get much closer to building it than would have been possible for most non-engineers a few years ago.

I am wary of taking that claim too literally. English is not programming, and being able to explain a product idea does not suddenly give somebody the engineering judgement required to make secure, reliable software.

But the larger point landed with me because I can see a version of it happening in my own work.

For most of my career, writing ended in an artefact. I researched something, interviewed people, worked out the argument and produced an article, customer story, guide or campaign.

Increasingly, I find myself doing something slightly different.

I am still writing. But I am also building systems around the writing.

The document is no longer always the end point

I wrote yesterday about how AI made my humanities degree feel technical. My English and journalism training did not suddenly turn into computer science. What changed was the interface. Natural language became one of the ways I could operate much more capable technology.

The practical consequence is only just becoming clear to me.

Once you can describe a process to a model, ask it to help structure the process, connect it to files and tools, test the output, change the rules and keep iterating, the distance between having an idea for how work should happen and creating a working version of that idea becomes much shorter.

That does not necessarily mean building an app.

Sometimes the product is a workflow. Sometimes it is a structured memory. Sometimes it is a routing rule that decides where a task should go. Sometimes it is a small system that notices what information is missing before another piece of work starts.

Those things used to feel like the territory of a product team or an operations team. I am increasingly finding them inside editorial work.

I keep solving editorial problems by building things

Editorial Intelligence itself started as an argument.

I was trying to describe what happens when editorial judgement, organisational knowledge and AI become connected. The original problem was mostly conceptual: content teams know more than their published output suggests, but much of that knowledge disappears between projects.

Then the argument started demanding infrastructure.

If prompting is becoming routing, where does the routing logic live? If useful evidence should survive the article that first commissioned it, what structure preserves it? If a piece of work is still alive across several conversations and tools, what acts as the save point? If a customer interview contains more useful evidence than the final story can hold, how do you keep enough of that evidence available for the next legitimate use?

I have found myself creating repositories, schemas, evidence records, relationship fields, publishing rules and workflows to answer those questions.

None of those things is especially impressive as software. That is not the point.

The interesting part for me is that I did not start by wanting to build software. I started with editorial frustrations that a document alone could not solve.

The problem with knowledge work is how much of it is alive at once became a question about state and memory, while from one customer story to an editorial system became a question about preserving evidence after the first asset ships. Routing became a question about which model, tool, source or human should handle which part of the job.

Once the problem is framed that way, writing the explanation and designing the thing start to overlap. The article can still matter, but it is no longer automatically the final form of the solution.

Writers already spend a lot of time modelling users

There is another reason writers may be unusually well placed to experiment here.

A good writer spends a large amount of time inside somebody else’s head.

What does this person already know? What are they trying to do? Where will they get confused? Which detail changes the meaning? What information needs to arrive first? What can be removed without breaking the argument? What question are they really asking underneath the one they typed?

Journalism adds another layer. What is the person not telling me? What would make this claim more credible? What follow-up question will reveal whether the neat answer survives contact with reality?

Those are not identical to product skills, but there is a family resemblance.

A product has users rather than readers, but both punish unclear assumptions. A workflow has states rather than paragraphs, but both depend on sequence. An interface has choices rather than sentences, but somebody still has to anticipate what the person on the other side is trying to accomplish.

Writing teaches you to care about the experience of receiving information. Product work asks you to care about the experience of doing something with it, and AI makes it easier for one person to move between those two.

The strongest skill may be specifying what good looks like

This is where the phrase “English is the new programming language” becomes more useful if you soften it.

The valuable capability is not simply fluency. Plenty of fluent instructions still produce terrible systems.

The more useful skill is specification.

Can you explain the job precisely enough that another person or system can act on it? Can you state what success looks like? Can you describe the constraints? Can you recognise when an output is technically valid but wrong for the actual purpose? Can you find the edge case that exposes the assumption underneath the design?

Editors do versions of this constantly.

“This is well written” is rarely enough. The real editorial instruction is more like: the opening promises an argument the evidence never supports; this example belongs later because the reader does not yet understand why it matters; this quote is vivid but cannot carry the claim you have put on top of it.

That is specification plus judgement.

AI gives that capability a new surface. Instead of using it only to improve an article, you can sometimes use it to define the behaviour of a system.

But writers should not romanticise the leap

There is a seductive version of this argument where writers discover that they were secretly engineers all along.

I do not believe that.

Once something becomes a real product, the disciplines writers do not know become obvious very quickly. Data structures matter. Security matters. Permissions matter. Reliability matters. Error handling matters. Versioning matters. Testing matters. A prototype that works when its creator is sitting next to it is not the same thing as a product other people can depend on.

Natural-language development can also hide complexity. It is possible to ask an AI coding tool to make something happen and get a convincing result without really understanding what has been created underneath.

That is useful for experimentation. It can also create false confidence.

So the opportunity is not that writers can ignore engineering. It is that they can now get far enough into building to discover which parts of an idea are real, which are vague and where specialist expertise becomes necessary.

That is a meaningful change.

Product thinking changes the questions I ask

The bigger effect on me has not actually been that I can make more things. It is that I increasingly look at an editorial problem and ask a different question.

A few years ago, if useful knowledge kept disappearing after projects, my instinct would probably have been to write guidance explaining why teams should preserve it better. Now I am more likely to ask: what is the smallest structure that would make preservation happen as part of the work?

If several models are good at different tasks, I do not only want an article explaining the differences. I want to know whether the work can be routed between them without creating bureaucracy.

If a customer story contains reusable evidence, I do not only want to say that teams should reuse it. I want a record that keeps the proof point, source, context and unanswered question alive after publication.

That is product thinking, even when the eventual implementation is modest.

The important shift is from describing a better behaviour to designing conditions that make the behaviour easier.

This may be another way editorial work moves upstream

I have been arguing for a while that editorial jobs are moving upstream. AI makes production cheaper, which puts more value on evidence, judgement, narrative and orchestration.

Product building may be another part of the same movement.

If the writer’s value is no longer confined to producing the final words, there is no obvious reason the writer has to stop at the document boundary.

The person who understands the audience, the evidence, the workflow and the failure points may be well placed to help design the system that produces the outcome in the first place.

Not every writer will want to do that. Plenty of excellent writing should remain exactly that: writing.

But I suspect more writers will discover that some of the problems they have spent years describing are now problems they can prototype solutions to. That feels important to me because it changes the direction of travel.

The question stops being whether AI can write the article. It becomes whether the writer understands the problem well enough to build something more useful than another article about it.