GenAI for content: Have we come far?

Last year, I sent an article for publishing that is still waiting for review. It is a case study about how I was using AI to build Gregory-MS.

The takeaways were that, at the time, AI was being useful to break the knowledge barrier between content editors and developers. None of my tests produced content that was accurate or good enough for publishing.

In the meantime, there were new models launched, and through trial and a lot of error, we started testing the boundaries.

We learned how to structure prompts better (overview, context, objectives, requirements, instructions). (Best practices for prompt engineering, aka better writing)

AI suppliers started developing Model Context Protocol (MCP) servers to interact with other apps.

We started using system prompts and user prompts to ensure some level of consistency in the output. A system prompt is processed for every user request; it can be something like the style of writing, some part of the project context that never changes, some instructions that must always be followed, commands that should never be run, etc.

If I were to write that paper today, it would be very different.

We are at a point where the first draft that comes from AI can pass for actual human work, done by someone with little knowledge of the project we may be working on.

Gregory-MS was missing a support page, and I decided to see how far AI could do it alone. The result is very good, in my opinion, but came with a few requirements behind the scenes. Take a look.

What I needed to change:

1. The images and photos did not fit the content, and one of them did not exist.
2. Titles and other parts of the text were not true or could have been written better.
3. A section of the page did not make any sense in the context we are working on.

What simply worked out of the box:

1. The overall content made sense.
2. The FAQ's address real issues.
3. The AI used design components that were consistent with the rest of the website.

The whole process took about 20 - 30 minutes. I didn't pay attention to it.

Behind the Scenes

Getting to this point meant a lot of groundwork for the project and changes to the way I used to develop websites. A few years back, I started using a website framework that uses plain text files and HTML. It's called Hugo. It's fast and uncomplicated for the most part. And the documentation available is perfect to provide context to a LLM.

That's step 1: the LLM can jump straight to the code and use the codebase for context.

Step 2 is the tooling. I am not using the web interface of a LLM, instead, I subscribed to Microsoft CoPilot and use it from Visual Studio Code (VS Code). These are not your typical tools for most Comms Professionals.

Still in this step, I have been getting good results from Claude Sonnet 4, and that's what I picked inside VS Code.

Step 3 is not just about the prompt.

I am passing context to Claude in 3 ways. The codebase, the custom instructions file inside the project, and other supporting files or documents. There is a file called copilot-instructions.md with this content:

• Project Overview
  • Folder Structure
• Libraries and Frameworks
• Coding Standards
• Testing
• Ul guidelines
  • Foundational Principles
  • Typographic Excellence
  • Color Theory Application
  • Spatial Awareness
• Human Interface Elements
  • Core Interaction Principles
  • Control Design Guidelines
    • Buttons
    • Input Controls
    • Menus and Lists
    • Motion and Animation
  • Responsive States and Feedback

The outline and most of the content in this file come from a blog post by Simon Willion.

Highlights from the Claude 4 system prompt

Anthropic publish most of the system prompts for their chat models as part of their release notes. They recently shared the new prompts for both Claude Opus 4 and Claude …

Simon Willison’s WeblogSimon Willison

The prompt was the next step, here it is in full.

I need your help to draft a support page. 

You can use the information from the PDF file to understand the features and the full context of the project.

# the support we can provide
- This site gathers papers from different sources but we do not validate their scientific integrity. we only try to filter the papers that indicate benefits to patients or the development of new treatments
- We are always open to respond by email team@gregory-ms.com 
- We encourage people to send an email if they find a bug or have a suggestion

# instructions
- draft a support page based on the information above and use the #file:researchers content as an example

Let's break it down.

First, I always use Markdown when writting prompts, and even other pieces of content. It's a way to write that was developed by John Gruber, and that allows you to convert your text to a Word document, an HTML or PDF file, and many other formats.

You will also notice I mentioned a PDF file. That file is the press kit for the project, because while the copilot-instructions file contains project requirements, the press kit contains actual project background.

Next, there is a mention to a #file:researchers file that is actually a directory with the content of the Researchers section for Gregory-MS. That page contains design elements and metadata that are needed for Hugo to turn a text file into a webpage.

That's it. Claude delivered something that could have been published even though it had some information that wasn't quite right.

For me, the main takeaway from this is that the time spent preparing the press kit and writing the copilot-instructions file paid off in the time it took to create the page.

Also, Claude took over two roles by itself. The role of a frontend designer and of a copywriter. From my side, I took the role of manager by identifying the need and providing the instructions, and the role of editor and design director when I reviewed the text and picked new images.

There are a few obstacles to implement this in other projects, specifically the content management systems used by websites rarely rely on text times. If I wanted a page using Wordpress or Ghost, I would need an MCP server that the LLM could use to interface with it, and I am not sure if the context it could access would be as rich as my copilot-instructions and the PDF file.

As communication professionals we need to start rethinking our tools and our methods to accomplish tasks. But instead most of us seem to be chasing the best prompts and the shiny AI tools that keep popping up.

Your thoughts?