Generative AI can help agencies get more done, but speed is not especially useful if the work still takes several rounds of correction.
Prompting, then, is less about finding clever ways to talk to AI and more about giving it what it needs to do the job well. You want enough direction to get a useful result without spending ten minutes writing a prompt for a task that should take five.
That applies whether you are asking AI to develop a content brief, write website copy, generate a site, build a widget, prototype a web app, or sort through client feedback. The specifics change, but the basic challenge does not: how much information does the model need, and how clearly do you need to define the result?
So, how do you get better results without making prompting a job of its own?
Before writing a detailed prompt, decide what a useful response actually needs to accomplish.
MIT Sloan’s guidance on effective prompting emphasizes three fundamentals: provide relevant context, be specific about the task, and build on the conversation. These ideas work together. Once you know what you need from the response, it becomes much easier to decide which information and instructions the model needs.
Say you are asking AI to help with copy for a client’s new service page.
“Write a service page for an accounting firm” gives the model a task but leaves most of the important decisions up to it.
Instead, you could explain that the firm serves independent restaurants, that the page is for restaurant owners comparing outsourced bookkeeping providers, that the goal is to encourage consultation requests, and that the copy should avoid technical accounting terminology.
The same principle applies when the output is a website or piece of functionality rather than text. “Build a mortgage calculator” leaves questions about inputs, calculations, validation, design, responsiveness, and user behavior unanswered. You will probably get something that resembles a mortgage calculator, but perhaps not the one you need.
A better prompt could specify that the calculator is for a mortgage broker’s website, should accept home price, down payment, interest rate, and loan term, and should display the estimated monthly principal and interest payment. You might also specify how it should behave on mobile, how invalid inputs should be handled, and how its visual design should fit the surrounding site.
You do not need an elaborate prompt explaining how the AI should behave. You just need to describe the work clearly.
For more involved tasks, it can help to think about six things:
Not every prompt needs all six. “Give me five alternatives to this headline” may be perfectly adequate. The structure becomes more useful as the task becomes more complex or the consequences of a poor answer increase.
It is easy to assume that more context will produce a better result. Sometimes it will. Sometimes it just gives the model more to wade through.
A 2024 survey of efficient prompting methods looks at efficiency in terms of getting comparable or better model performance while using fewer human or computational resources. Among the approaches it examines are prompt optimization and prompt compression.
There is a useful lesson here for everyday agency work: every piece of context should have a reason for being there.
If you are asking AI to write a landing-page headline, it may need the value proposition, audience, offer, brand voice, and a few examples of existing messaging. It probably does not need the client’s entire brand strategy document.
If you are generating a website, more context may be justified. The model might need to understand the business, site goals, audience, page structure, brand direction, required functionality, and content hierarchy. But even then, context is most useful when it helps the model make a specific decision.
Think of context as packing for a trip. The goal is not to fit everything you own into the suitcase. It is to bring what you are likely to use when you get there.
Before adding something to a prompt, ask what decision it will help the model make. If you cannot think of one, you can probably leave it out.
When agencies use AI to generate websites, widgets, and web apps, a prompt has to describe more than what the result should look like.
You also need to explain what should happen.
Suppose you want to create a quote-request widget for a landscaping company. You might describe the layout, fields, typography, and button. But what happens after someone clicks that button? Which fields are required? What should happen if an email address is invalid? Does the user see a confirmation message? Should certain selections reveal additional questions?
Those details are easy to overlook because people naturally describe interfaces visually. But a working interface is a collection of behaviors as much as a collection of elements.
For interactive work, it helps to think through three layers:
You do not have to specify every implementation detail. In many cases, letting the AI make reasonable choices is part of what makes it useful. But the behavior that matters to the client or end user should not be left to chance.
Sometimes the quickest way to explain what you want is to show it.
MIT Sloan distinguishes between zero-shot prompting, where a model receives instructions without examples, and few-shot prompting, where examples help establish the pattern you want it to follow.
Examples are particularly handy when you know what “good” looks like but find yourself writing a paragraph of rules to describe it.
For copy, that might mean supplying three meta descriptions that capture the style you want.
For website generation, it might mean providing examples of the visual direction, page structure, or interaction pattern you have in mind. For a widget, you might provide a sample input and the result you expect. For a web app, you might show how data should be organized or describe a few representative user journeys.
Examples can communicate patterns that are surprisingly difficult to express as instructions.
There is one catch: examples teach the model the pattern you give it, not the pattern you had in mind. If the examples are mediocre, you have done a very good job of explaining how to produce mediocre work.
You can ask AI to generate an entire website or application in one prompt. That does not mean you always should.
As the number of requirements increases, it becomes harder to spot where a misunderstanding entered the work. If the finished result is wrong, you may find yourself revising several interconnected pieces at once.
For larger builds, a staged conversation can be easier to manage.
For a website, you might begin with the goals, audience, and required pages, then review the proposed structure before moving into individual pages. Once the structure is right, you can refine content and visual direction.
For a web app, you might start with the user’s goal and core workflow. Once that works, move on to edge cases, states, styling, and secondary features.
This does not mean turning every build into a long sequence of prompts. The amount of staging should match the complexity of the work. A simple testimonial slider probably does not need a planning phase. A client portal with several workflows probably does.
There’s a clear benefit here, it is cheaper to correct a misunderstanding before the model has built five more things on top of it.
When the first response misses the mark, you typically don’t need to start again.
MIT Sloan recommends building on the conversation. Research into automatic prompt engineering takes a related approach, examining ways to generate, evaluate, and refine prompts based on how well they perform.
You can use the same idea in a much simpler way.
If an AI-generated brief is too broad, tell it which sections need more specificity. If its copy sounds generic, point out the phrases that could just as easily describe a competitor.
When you are generating a website or app, feedback can be just as concrete. “Make the design more modern” gives the model plenty of room to guess. “Reduce the visual weight of the header, remove the card treatment from the services section, and give the primary call to action more separation from the navigation” tells it what you actually want changed.
The same goes for functionality. Rather than saying “the form doesn’t work right,” describe the behavior you expected, what happened instead, and the conditions under which the problem occurs.
Specific feedback makes the next response more useful.
There is also something worth paying attention to here: if you find yourself giving the same correction again and again, the correction probably belongs in the original prompt.
A prompt you will use once does not deserve the same attention as one your team will use hundreds of times.
Research into automatic prompt engineering questions the assumption that a person’s first attempt at an instruction will necessarily be the best one. Researchers have explored methods for generating possible prompts, testing their performance, and selecting or refining stronger versions.
Agency teams can borrow the basic idea without making it complicated.
Suppose your team regularly uses AI to turn client discovery notes into website briefs. Instead of adding another instruction every time something goes wrong, keep a standard prompt and occasionally test changes against a few representative projects.
The same idea can apply to generation workflows. If your agency frequently builds websites for businesses in a particular vertical, you may find that certain instructions consistently lead to better page structures, calls to action, responsive behavior, or content organization. Those lessons can become part of the starting point for the next project.
Ask whether the prompt works for different types of clients. Look for instructions that consistently improve the result and ones that seem to make little difference. Notice where the model makes the same mistake repeatedly. See whether an example could replace a long explanation.
Most important, remove things as well as adding them.
Prompts have a tendency to grow. Someone gets a bad result, adds a rule, and leaves it there forever. Six months later, nobody remembers why half the instructions exist.
A little maintenance goes a long way when the prompt is something the whole team uses.
Prompt efficiency is not only about how much time you spend writing the prompt. The amount of text you give the model matters, too.
Longer prompts use more of a model’s available context and require more processing. The efficient-prompting research describes text-to-text prompt compression as preserving useful information while removing redundant material or summarizing longer inputs.
You can apply the same principle without using a specialized compression tool.
In a long AI conversation, for example, you might eventually ask the model to summarize the project into a short brief containing the decisions made so far, the requirements, relevant client preferences, and any unresolved questions. You can then use that brief as the starting context for the next stage of work.
This can be especially useful during website and app generation, where a conversation may accumulate design decisions, content revisions, functionality requirements, and bug fixes over many rounds.
Instead of expecting every earlier exchange to remain equally important, periodically restate the current requirements. Keep the decisions that still matter and drop the paths you decided not to pursue.
The point is not to make every prompt as short as possible. A short prompt that leaves out essential information is not efficient. You are looking for the smallest amount of context that still gives the model what it needs.
Prompts often get unwieldy because permanent requirements and one-off instructions end up mixed together.
Some things rarely change: brand terminology, editorial rules, prohibited claims, accessibility expectations, formatting requirements, coding conventions, or your agency’s preferred approach to responsive design.
Other things change every time: the client, page, campaign, functionality, audience, content, or source material.
Keeping those two groups separate makes reusable prompts much easier to work with.
For example, your agency might have a standard set of expectations for generating a lead-generation website: responsive layouts, clear heading hierarchy, accessible forms, sensible error states, and no placeholder links in the finished build. The project prompt can then focus on what is distinctive about the client and the site you are creating.
It also makes troubleshooting easier. If the result is poor, you have fewer places to look. Is the problem in the reusable instructions? Is the project context incomplete? Or was the task itself unclear?
AI can help with the prompt itself.
One practical takeaway from research into automatic prompt engineering is that language models can participate in generating and refining instructions.
For an important prompt your team uses regularly, give the model the prompt along with a few examples of good and bad outputs. Ask it to point out ambiguous instructions, repetition, conflicting requirements, and information that appears to be missing. Then ask it to suggest revisions.
For a website or app-generation prompt, you can also ask it to identify requirements that are underspecified. What happens on mobile? Are there missing states? Is expected form behavior clear? Are there accessibility considerations you have not addressed? Are two requirements in conflict?
Do not assume its rewrite is better just because the model says it is. Try it on a few real examples and compare the results.
This can be especially useful for prompts that have been around for a while. Teams often respond to each bad result by adding another rule. Eventually, the prompt becomes a record of everything that has ever gone wrong rather than a clear explanation of what you want.
At that point, editing is usually more useful than adding.
A shared prompt library is useful only if people can tell what each prompt is for and how to use it.
For prompts tied to frequent agency tasks, include a short explanation of their purpose, the information someone needs to provide, an example of a good result, and any common situations where the prompt is likely to struggle.
And revisit them from time to time.
A content-brief prompt that worked well six months ago may behave differently with a newer model. The same is true of a prompt used to generate a site, component, or app. As models become better at handling larger tasks, some instructions may become unnecessary while other capabilities may be worth taking advantage of.
The research on efficient prompting offers a useful way to think about this. The best prompt is not necessarily the longest, most detailed, or most sophisticated one. It is the one that gets you the result you need without asking for more time, context, or processing than the job requires.
You do not need everyone at your agency to become a prompt engineer.
It is more useful for people to get good at defining what they need, deciding which context matters, showing examples when appropriate, describing expected behavior, and giving clear feedback when the first attempt falls short.
That applies to a two-sentence piece of copy and to an AI-generated website. The difference is mostly in how much there is to define and verify.
Start with a simple prompt. Add detail when the model gives you a reason to. For interactive work, describe what the user should be able to do and what should happen next. Breaking larger builds into stages when reviewing the pieces separately will save you trouble later. Use examples when they are clearer than another paragraph of instructions. Cut context that is no longer helping. And spend your time improving the prompts your team actually uses often.
Shakespeare, famously, wrote in Hamlet that “brevity is the soul of wit.” Perhaps its the soul of your work, too.
