In this week’s In-Ear Insights, Katie and Chris discuss how the software development life cycle (SDLC) applies to prompt engineering in generative AI, why the prompt development life cycle (or prompt engineering life cycle) is a good idea, and a real-life application of it.
Watch the video here:
Can’t see anything? Watch it on YouTube here.
Listen to the audio here:
- Need help with your company’s data and analytics? Let us know!
- Join our free Slack group for marketers interested in analytics!
[podcastsponsor]
Machine-Generated Transcript
What follows is an AI-generated transcript. The transcript may contain errors and is not a substitute for listening to the episode.
Christopher Penn: This week on In-Ear Insights, let’s discuss prompt engineering and software development—two seemingly disparate concepts that surprisingly converge. Here’s why: programming involves writing a sequence of text instructions for a machine to produce a repeatable, reliable result. You write code in C++, Python, or Java to perform a task and generate an output. Ideally, good code yields good results.
When you write prompts for generative AI and large language models, you’re essentially programming, just in a language like English, French, or Danish instead of C++. This means adopting good software engineering practices becomes crucial. You’re writing code, so you should protect it, audit it, and manage it effectively.
Katie, you’ve managed development teams—including me, bless your heart—when it comes to prompt engineering, development, internal sharing, and debugging. Many people, especially marketers, seem to just wing it instead of having a scalable, structured approach. So, when managing the prompt development lifecycle, what should people consider?
Katie Robbert: Requirements are paramount. Let’s take a step back. I was just checking our website for our version of the SDLC (software development lifecycle). We probably have it somewhere, maybe as an In-Ear Insight.
Chris, this topic arose last week when you drew a parallel between the SDLC and prompt engineering, highlighting the significant overlap. The question is, can we adapt the SDLC for prompt engineering? Absolutely!
The SDLC, like any project management or development lifecycle, has a few key phases: requirements gathering (business goals, development goals, needs, and approach), process definition (tools and methods), execution, testing, and iteration. It aligns surprisingly well with the five Ps framework: purpose, people, process, platform, and performance.
In this context, the purpose is to write a prompt for a specific task. People involve gathering stakeholder requirements. Process encompasses the prompt’s content, research needs, iterative testing, and validation methods. Platform seems straightforward—the environment for writing the prompt—but it might also involve data extraction from various platforms, feeding back into the process. Finally, performance measures the success of the task. While the SDLC is well-established in development communities, the five Ps framework provides a versatile lens.
There’s substantial overlap with prompt engineering because, at its core, you’re “developing” something. Development isn’t limited to writing code at a computer; it can encompass creating anything repeatable.
That was a long-winded way of saying yes, there’s a clear connection between the two.
Christopher Penn: So, where do we start? Currently, people tend to open ChatGPT, Google Gemini, or Anthropic Claude and start typing without much planning. For instance, someone might try to clean up podcast transcripts with a simple prompt like “summarize this transcript” or “edit the grammar in this transcript.”
We know that’s not the most effective way to utilize a language model. Language models are like brilliant interns: intelligent but requiring guidance.
I could ask Gemini about best practices for cleaning up transcripts, which aligns with our four power questions framework (available at TrustInsights.ai/powerquestions). However, jumping right in might not be the best approach.
Katie Robbert: Right, you’re asking questions you already know the answers to. It’s similar to software development. One challenge I faced with my development team was their eagerness to jump into action without thorough requirements gathering. They felt it was time-consuming when they already had a general idea of what needed to be done. But as you delve into the nuances and features, you realize it’s not a simple one-to-one translation.
In prompt engineering, if you start building an ideal customer profile without clearly defining desired outcomes, you waste time and resources without achieving your goal.
It boils down to the cost of wasted time, resources, and missed opportunities. Can you afford not to get what you’re after? Usually, the answer is no. That’s why upfront requirements gathering is crucial.
For instance, if you’re using generative AI for an ideal customer profile, ask yourself: “Do I have all the necessary information, or am I winging it?”
Christopher Penn: Precisely. For those unfamiliar, the SDLC generally involves planning, requirements gathering, building, testing, debugging, deployment, and maintenance. These steps also apply to prompt engineering.
In our example, we want a prompt to clean up podcast transcripts. Requirements become surprisingly complex because language models tend to rewrite and summarize, potentially removing your voice. So, we want to ensure the prompt cleans up grammar, punctuation, and spacing while preserving our distinct speaking styles.
What else should we consider during requirements gathering? How do you identify what to ask or specify?
Katie Robbert: One trick we used was asking stakeholders to list what they didn’t want, which helped narrow things down. In this case, you might specify that you don’t want the model to change your voice, rewrite sentences unnecessarily, or alter the meaning. This approach helps clarify your requirements.
For example, cleaning up incomplete sentences might be desirable, but you need to explicitly instruct the model to leave them as-is to maintain your voice.
Christopher Penn: Exactly. Another essential step is asking the system what you might have missed. Once you have the requirements and user story, ask, “What did I forget to implement?” The model will provide clear feedback.
For example, when I did this with the transcript prompt, it asked about the language (USA English), the type of transcript (podcast), the number of speakers (two), and specific technical terms or jargon used. These are all part of both requirements gathering and the prompt itself since it’s in plain language.
Katie Robbert: It highlights a common challenge with requirements gathering: people perceive it as a lengthy, time-consuming process. But as you’ve demonstrated, Chris, you can document these requirements once and reuse them repeatedly. For In-Ear Insights, we always have two speakers and consistent branded and technical terms.
I have to correct the title in our Marketing Analytics and Insights Live show transcript every week because it’s transcribed as “SWOT analysis” instead of “So what.” This could be due to my pronunciation or limitations of the transcription software. Regardless, we can build these details into our requirements to avoid repetitive manual corrections.
I think many of us, myself included, fail to retain this information and start from scratch each time, leading to frustration and the misconception that generative AI is inefficient. Your approach demonstrates the value of building a reusable library of prompts.
Christopher Penn: Absolutely. And reusability is a core principle of software development.
Let’s examine this prompt (available at TrustInsights.ai/youtube). It starts by stating the objective: editing transcripts for clarity. Key objectives include cleaning up grammar, punctuation, and spelling errors, and applying formatting and spacing.
The context section specifies speaker names, transcript type, target audience, language, and specific terms.
The instructions section, as you mentioned, Katie, outlines what not to do: paraphrase, summarize, alter wording or sentence structure, remove filler words, false starts, or speech interruptions. It also specifies keeping contractions, slang, and acronyms, using em dashes, excluding non-verbal cues, and breaking apart run-on sentences. Additionally, it provides guidance on spelling out numbers and handling duplicate words, sentences, and phrases. Finally, it instructs the removal of stop words and sentence endings like “right?”. Examples are provided for clarity.
This is a comprehensive prompt resulting from extensive requirements gathering.
Katie Robbert: It’s incredibly scalable, considering we have hundreds or even thousands of transcripts that need cleaning. Before generative AI, we attempted to do this manually with inconsistent results and loss of our voices. This prompt provides a clear set of instructions that can be applied consistently across all transcripts.
To reiterate, if you’re unsure where to start with requirements, begin by listing what you don’t want. This helps narrow down the possibilities and expedite the process.
Christopher Penn: Exactly. And in the SDLC, maintenance also involves iteration. If the model misbehaves, identify the issue and update the prompt with new rules or examples using few-shot learning. The more guidance you provide, the better the model performs. This aligns with the testing, QA, and maintenance phases of development.
While writing prompts may seem non-technical, a structured approach like the prompt development lifecycle ensures reliability and scalability. You can even automate the process by incorporating the prompt into a Python script to process transcripts automatically.
Katie Robbert: You made a point I’d like to unpack. While the SDLC applies to software development, it’s a framework applicable to both technical and non-technical scenarios. That’s why I developed the five Ps framework: a decision-making framework suitable for various contexts.
The SDLC, project lifecycle, and product development lifecycle are all decision-making frameworks designed to guide you from start to finish, from idea to outcome.
Don’t be intimidated by the technical aspects of prompt engineering or the SDLC. View them as frameworks—sets of instructions or recipes—accessible to individuals of all skill levels. Whether following a simple recipe on a box or a complex one from a renowned chef, you’re still following instructions to achieve a desired outcome.
Christopher Penn: Precisely. The prompt development lifecycle is essentially a recipe for creating recipes.
Katie Robbert: A rudimentary Matrix, indeed.
Christopher Penn: Very Inception-like.
We’ll likely publish a more detailed version of this as an In-Ear Insight on our website. In the meantime, if you have prompt development tips, please share them in our free Slack group at TrustInsights.ai/analyticsformarketers, where over 3,000 marketers discuss AI, analytics, and data.
Wherever you’re watching or listening, please leave us a rating and review to help others discover the show. Thanks for tuning in, and we’ll catch you next time!
|
Need help with your marketing AI and analytics? |
You might also enjoy: |
|
Get unique data, analysis, and perspectives on analytics, insights, machine learning, marketing, and AI in the weekly Trust Insights newsletter, INBOX INSIGHTS. Subscribe now for free; new issues every Wednesday! |
Want to learn more about data, analytics, and insights? Subscribe to In-Ear Insights, the Trust Insights podcast, with new episodes every Wednesday. |
Newsletter
Podcast
