Why My AI Prompts Sometimes Run to 30 or 40 Pages

There is something slightly ridiculous about spending hours writing instructions for a tool that is supposed to save you time. You open ChatGPT, describe what you want, and expect it to help you write an article, develop a software feature or solve a problem. The attraction is obvious: instead of doing everything manually, you can explain your idea in ordinary language and let AI handle part of the work.

And yet, some of my prompts are several pages long. Others can grow to 30 or even 40 pages. I'm not talking about research papers or lengthy documents I want AI to analyse. I mean the actual instructions I prepare for it to follow, sometimes before the main work has even started.

At first glance, that sounds excessive. Why would anyone need dozens of pages to ask a machine to do something? Surely, if AI is supposed to simplify our work, preparing such elaborate instructions rather defeats the purpose?

I've wondered about that myself. The answer has something to do with the complexity of the projects, something to do with how AI interprets instructions, and quite a lot to do with the corrections and restrictions that accumulate along the way. There is also a less comfortable possibility: sometimes I may be making the process more complicated than necessary.

It Usually Starts With a Perfectly Reasonable Request

Most of my work with AI doesn't begin with an enormous document. It might start with something as ordinary as asking for a blog article, adding a feature to a PHP application or improving an interface that doesn't look quite right. The initial request can be surprisingly short, especially when the task appears straightforward.

Imagine asking AI to write an article about the difference between a software prototype and a finished product. The first result might be perfectly readable, with a clear introduction, several informative sections and a sensible conclusion. There may be nothing obviously wrong with it. But perhaps it sounds like a textbook rather than something a person would enjoy reading on a personal blog.

Maybe every section contains a list of recommendations. The introduction makes a grand statement about technology transforming the world, while the conclusion encourages readers to embrace innovation. These are familiar patterns in AI-generated writing, and although they may suit certain types of content, they aren't what I want for my own website.

So I start explaining what I actually mean by a good article. It should sound natural without becoming careless. It should explore an interesting subject rather than automatically turning into a tutorial. It shouldn't present me as an industry expert, invent experiences I've never had or describe every decision as a remarkable success.

The next version may be better, but another problem appears. Perhaps several sections repeat the same argument, or the article introduces technical claims that need checking. Maybe the text is accurate but still lacks personality. Each revision helps me identify something that wasn't clear in the original request, and some of those discoveries eventually become permanent instructions.

Coding follows a similar pattern, although the consequences can be more serious. A request to change one part of an existing application may require explaining how the system works, which files are involved, what must remain untouched and how the new functionality should interact with everything else. The actual change may be small, but the surrounding context isn't.

Every Mistake Adds Another Paragraph

I suspect one reason my prompts have become so long is that they gradually collect the history of previous corrections. When AI produces something I don't like, I can fix the immediate result, but I also have to decide whether the same problem is likely to appear again. If it is, adding a clarification to the instructions can seem more sensible than repeating the same correction every time.

For example, a content prompt may accumulate rules about avoiding promotional language, checking factual claims and distinguishing personal experience from general information. A coding prompt may acquire restrictions about preserving existing functionality, following the application's architecture and not introducing features that were never requested.

Some of these additions are quite specific. Others become broader principles that apply across many tasks. A few examples illustrate how an ordinary correction can turn into a reusable instruction:

• Invented functionality: If AI describes a product feature that doesn't exist, the prompt gains a requirement to use only confirmed product information.
• Unwanted changes: If a coding modification affects an unrelated part of an application, the instructions become more explicit about preserving existing behaviour.
• Generic writing: If an article sounds like a promotional brochure or textbook, the editorial rules become more specific about tone and style.
• Unsupported claims: If AI presents an assumption as a fact, the prompt gains clearer expectations about accuracy and uncertainty.

Individually, these instructions are reasonable. Collectively, they can become a surprisingly large document. What makes the process interesting is that the prompt is no longer just a description of the task. It also contains a record of problems I've encountered and decisions I've made about how the work should be approached.

A long prompt can become a record of everything that previously went wrong, everything that needs protecting and everything the creator has decided matters.

There is a curious contradiction here. You might expect that the more experience someone has with AI, the shorter their prompts would become. After all, experience should make it easier to communicate clearly. But it also makes you aware of details you didn't initially know were important. A request that seemed perfectly clear at the beginning may turn out to have several possible interpretations.

Of course, not every mistake deserves another permanent rule. Sometimes the problem is missing information, a poorly defined task or a misunderstanding that would be better resolved through a short conversation. And sometimes AI simply gets something wrong despite having clear instructions. Adding more text cannot prevent every failure, and an excessively detailed prompt can create problems of its own.

Still, it's easy to see how a document grows from two pages to ten, then twenty, without anyone deliberately deciding to write a miniature book.

Writing an Article and Writing Code Are Two Different Conversations

I use AI for both content creation and software development, but the instructions for these activities serve different purposes. With content, much of the difficulty involves tone, perspective, factual accuracy and the overall reading experience. With coding, the difficulty often lies in technical dependencies, existing architecture and the consequences of changing something that already works.

Both activities require context, but the type of context can be quite different. This is one reason I don't think there is a single ideal prompt structure that works equally well for every task.

With content, the problem is often what the writing feels like

For my personal website, Cordinant, I have a master article prompt that defines the general editorial approach I want for blog content. It doesn't simply tell AI to write in a friendly tone or avoid grammatical mistakes. It describes the website, its audience, the subjects I write about and the kind of relationship I want the articles to have with readers.

These subjects include digital products, PHP development, product design, SEO and AI-assisted work. Although the topics vary, I want the articles to share a recognisable editorial approach without sounding as though they were produced from the same rigid template.

One of its central principles is Interesting Before Educational. I don't want every article to become a tutorial, complete with numbered instructions and a predictable list of lessons at the end. Sometimes an interesting article simply explores an idea, compares different perspectives or describes why something turned out to be more complicated than expected.

The prompt also addresses how personal experience should be handled. AI shouldn't invent stories about my projects, claim that I've achieved results I haven't achieved or present me as an authority on every subject I discuss. I prefer writing that acknowledges uncertainty and leaves room for different opinions.

Then there are the familiar habits of AI-generated content: grand introductions, motivational endings, repeated explanations and phrases that make ordinary decisions sound extraordinary. I don't need an article to tell readers that a simple development choice will transform their business. I would rather have a thoughtful discussion about something genuinely interesting.

Explaining all these preferences takes more than a sentence saying "write naturally". Even with a detailed editorial prompt, however, I still need to read the result, check its accuracy and decide whether it belongs on my website. A prompt can establish expectations, but it cannot replace editorial judgement.

With coding, the problem is often what already exists

Software development introduces a different kind of complexity. Imagine asking AI to add a new feature to an existing PHP application. If the application were being built from scratch, there might be considerable freedom in choosing its structure. An existing project, however, already has files, database tables, configuration settings, authentication mechanisms, interfaces and conventions that the new functionality must respect.

For example, I work on applications intended to run in relatively conventional PHP and MySQL hosting environments. That matters when discussing implementation choices, dependencies and deployment. A technically interesting solution isn't necessarily suitable if it assumes a different environment or requires changes that the project doesn't need.

The instructions may therefore need to explain the current architecture, identify relevant files, describe the requested changes and specify what must remain unchanged. Sometimes the most important part of a coding prompt isn't what AI should create, but what it must leave alone.

This becomes particularly relevant when a project develops through several stages. Each stage builds on earlier decisions, and a new feature may depend on functionality that already exists. A seemingly isolated modification can have consequences elsewhere, so the surrounding information matters.

There is a limit to how much background information is useful, though. Giving AI the entire history of a project may be unnecessary when only a few files and requirements are relevant. The challenge is deciding which details are essential for the current task and which are simply adding noise.

At Some Point, It's No Longer Just a Prompt

A 30-page prompt sounds strange if you imagine a prompt as a question typed into a chat box. It sounds less unusual when you think of it as a specification. Complicated projects have always required people to define objectives, document requirements, establish restrictions and explain how the finished result should behave.

Developers use technical specifications, designers work with briefs, editors follow style guides and businesses document their processes. None of these activities appeared because of AI. What has changed is that much of this information can now be written in ordinary language and passed directly to a system that helps produce the work.

A detailed prompt may contain several distinct types of information:

Once a prompt contains all these elements, the distinction between writing instructions for AI and documenting a project becomes rather blurred. In many cases, I'm doing both at the same time. The document helps AI understand the task, but it also forces me to think through requirements that might otherwise remain vague.

There is something worth considering here. If I spend time identifying problems, selecting an approach, defining boundaries and deciding what the output should look like, I've already completed a significant part of the intellectual work before AI generates anything. The machine may produce the code or draft the article, but that doesn't mean all the thinking began when I pressed Enter.

In that sense, a detailed prompt can become a separate working document: a structured representation of the decisions behind the project. It may not be useful to anyone else, and it certainly doesn't guarantee a successful result, but it has a purpose beyond simply telling AI what to do next.

The Hidden Work Behind a Simple AI Result

One thing I find interesting about AI-assisted creation is how little the final result reveals about the process. You see a finished article, but not necessarily the editorial brief, corrections, fact-checking and revisions that preceded it. You see a working interface, but not the discussions about database structure, the rejected implementations or the effort required to preserve existing functionality.

This isn't unique to AI. A finished website doesn't reveal all the design decisions behind it, and a published article rarely shows how many drafts were discarded. Software users don't usually see the technical discussions that shaped a feature. But AI makes the difference between visible output and invisible preparation particularly noticeable because generating the first version can happen so quickly.

Someone might say they created an article or application feature with a single prompt. Another person may have spent several evenings preparing a detailed specification, working through multiple stages and correcting problems. Both may describe the result as AI-assisted, yet those descriptions reveal very little about the amount of human involvement.

They also tell us almost nothing about efficiency. A short prompt followed by extensive manual editing might take longer than a carefully prepared specification. Equally, writing dozens of pages for a simple task could be an enormous waste of time. The quality of the final result doesn't automatically reveal how efficient the process was.

I think this distinction is easy to overlook when people discuss AI productivity. The speed of generating an output is visible and impressive, but the preparation, evaluation and correction may be much less obvious. Those activities still matter, even when the first draft appears in seconds.

When More Instructions Become Another Problem

There is a point where detailed instructions stop helping and start competing with one another. Imagine a document that has been updated repeatedly over several months. One section asks for concise answers, another requests comprehensive explanations, an older instruction refers to functionality that has since changed, and a newer rule contradicts an earlier example.

The document may be long, but it isn't necessarily clear. In fact, the accumulated detail can make it harder for both the person writing the prompt and the AI system interpreting it to identify what matters most.

This is one of the more uncomfortable aspects of maintaining elaborate prompts. Adding a new instruction is easy; deciding that an old instruction is no longer necessary takes more thought. Once a rule has been introduced to prevent a particular problem, removing it can feel risky. What if the problem returns?

So the document continues to grow, sometimes retaining restrictions that are outdated, duplicated or relevant only to a previous task.

There are technical limitations as well. AI models have finite context windows, and their ability to follow instructions isn't uniform across every task or document length. A model may miss a detail, place too much emphasis on one section or satisfy some requirements while overlooking others. Longer prompts can also contain more opportunities for contradictory or ambiguous instructions.

At that point, adding more text may make the situation worse. The problem isn't necessarily the number of pages, but whether the information is organised, relevant and internally consistent.

One possible approach is to separate information that remains stable from instructions that change with each task. A blog's editorial principles can live in a master document, while an individual article receives a separate brief. A software application can have architecture documentation and coding conventions, while each development stage has its own specific requirements.

This doesn't eliminate complexity, but it gives different kinds of information somewhere more appropriate to live. It also makes it easier to update a project's rules without repeatedly rewriting everything from the beginning.

Breaking complicated work into smaller stages can help for similar reasons. Rather than asking AI to implement a large system in one operation, individual features can be developed and checked separately. Of course, this introduces another challenge: maintaining continuity between stages and ensuring that later changes remain compatible with earlier ones.

There isn't one arrangement that works for every project. A single detailed prompt may be perfectly reasonable for some tasks, while others are better handled through shorter instructions supported by separate documentation.

The Strange Economics of Saving Time

The promise of AI productivity often focuses on how quickly something can be generated. A draft appears in seconds, a block of code can be produced almost immediately, and several alternatives can be explored without starting from a blank page. These capabilities are genuinely useful, but generation time is only one part of the process.

Suppose I spend two hours preparing detailed instructions for a task that AI completes in five minutes. Was that efficient? It depends on what would have happened without those instructions. If the alternative required several hours of writing, coding or correcting mistakes, the preparation may have been worthwhile. If I could have completed the task myself in half an hour, perhaps not.

The calculation becomes more interesting when the prompt can be reused. My master article prompt, for example, establishes editorial principles that apply across different subjects. I don't need to explain from scratch every time why I dislike exaggerated claims, generic motivational endings or invented personal experiences.

A highly specific prompt for a one-off task is different. If it takes longer to prepare than the task itself would have taken, its value becomes questionable, particularly if the instructions are unlikely to be useful again.

Coding introduces another complication because a generated implementation still needs to be reviewed and tested. A detailed specification may reduce ambiguity, but it doesn't prove that the software works correctly or that the changes are compatible with the existing application. Testing and verification remain separate activities.

So the meaningful question isn't simply how long a prompt takes to write. It's whether the entire process, including preparation, generation, review, correction and testing, makes sense for the work being done. Without measuring those stages, I wouldn't want to make confident claims about how much time my approach actually saves.

Would I Prefer to Use Shorter Prompts?

Yes, in many situations. I don't particularly enjoy making something more complicated than necessary, and there is no achievement in writing 40 pages when four paragraphs would have done the job. For brainstorming, exploring a new idea, finding alternative headlines or discussing a small problem, a short conversational prompt is often perfectly adequate.

In fact, too much structure can make certain tasks less interesting. If every possible direction is defined in advance, there may be little room for unexpected suggestions. Sometimes I want AI to follow strict boundaries, but at other times I want it to question an assumption, offer an alternative or suggest something I hadn't considered.

Those are different kinds of interaction, and they benefit from different levels of instruction. A detailed specification can be useful when consistency, compatibility and specific constraints matter. A short question may work better when the purpose is exploration rather than implementation.

I also wonder whether the length of my prompts reflects how I approach projects generally. Working independently means moving between planning, development, interface design, content and promotion without separate people responsible for each area. Writing down requirements helps me keep track of decisions and makes it easier to return to a project without reconstructing every detail from memory.

In that situation, AI becomes both a tool for producing work and a reason to make my own thinking more explicit. The resulting documents may be longer than expected, but some of that detail would probably have needed to be considered anyway.

Still, I wouldn't want to confuse detailed preparation with actual progress. A beautifully organised prompt is only a set of instructions. It doesn't mean the article is worth reading, the application works or the software product is ready to use. Those things have to be judged separately, regardless of how much preparation went into creating them.

Maybe the Prompt Isn't Really the Interesting Part

I sometimes think about how strange this way of working would have sounded not very long ago. You want to write an article, so you first prepare a document explaining how the article should be written. You want to modify an application, so you describe its existing architecture, the intended changes and everything that must remain intact. Then you give those instructions to a machine, wait for the result and begin checking what it understood.

It's an unusual form of collaboration, particularly because so much of the effort can go into describing the work rather than directly producing it.

The surprising part isn't simply that an AI prompt can reach 30 or 40 pages. It's that explaining a task has become such a visible part of the creative and technical process. Some of that explanation is necessary, some is useful preparation, and some may be accumulated caution from previous mistakes. I suspect there are also instructions I could remove without losing anything important.

I'm still interested in finding that balance. I don't think the ideal prompt is necessarily the shortest or the longest one. It's the one that provides enough relevant information without burying the task under unnecessary complexity.

Perhaps my prompts will become shorter as I organise my projects better. Perhaps the most complicated ones will continue to resemble technical specifications rather than ordinary conversations. Either way, I find it slightly amusing that one of the skills involved in using AI is learning how to explain things to it.

And sometimes, apparently, I need 40 pages to do that.