Prompt engineering: how to communicate better with LLMs without relying on trial and error

You open ChatGPT, Copilot, or another LLM-powered tool and write: 'help me with this error.' The answer comes quickly, confidently, and in a well-formatted way—and yet it is not all that helpful. Maybe it is too generic. Maybe it assumes a stack you do not even use. Maybe it suggests a solution that looks good on paper but does not fit the real problem, no matter how hard you try.

This is a good starting point for talking about prompt engineering: not as a collection of magical phrases, but as the practice of making your intent more explicit to the model. Instead of throwing out an isolated question and hoping for the best, you describe the goal, context, constraints, expected format, and quality criteria.

This does not turn an LLM into an infallible source. It also does not eliminate review, testing, or critical thinking. But it reduces ambiguity and increases the chances of receiving a useful, verifiable answer that is easier to adjust.

TL;DR

• Prompt engineering is the practice of structuring instructions for LLMs more effectively.
• Good prompts make the following clear: goal, context, role, constraints, format, examples, and quality criteria.
• More context usually helps, but too much context—or context that is disorganized or irrelevant—can get in the way.
• LLMs can make mistakes, invent information, and sound confident even when they are wrong.
• Use the answer to support thinking, writing, planning, or diagnosis—not as a final decision without validation.

Prompt engineering is less about a magical phrase and more about making intent explicit

A vague prompt leaves many decisions up to the model.

For example:

Summarize this.

This request can produce very different answers depending on what the model considers important. Is the summary for studying? For sending to the team? For an executive audience? Should it include examples? Should it preserve technical terms? Should it point out open questions?

Now compare it with a more structured version:

Summarize the text below for a junior developer who is studying the topic.
Prioritize the main concepts, practical examples, and open questions.
Use up to 8 bullet points.
Clearly separate facts presented in the text from your own interpretations.

The second version is not perfect, of course. But it communicates the intent more clearly. It leaves less room for unwanted interpretations and makes it easier to review the output afterward.

In this sense, prompt engineering can be viewed as a kind of lightweight specification. It does not replace requirements, documentation, conversations with users, or acceptance criteria. Still, it helps organize what you already know about the task before asking for help.

This idea aligns well with careful development practices: clarity, short feedback loops, review, and continuous improvement. The value is not in 'getting a ready-made answer', but in improving the quality of the conversation with the tool.

Why do answers vary so much?

LLMs generate answers based on language patterns and the context they receive. They do not 'understand' a task in the same way someone on your team would after attending meetings, reading the code, learning the business constraints, and suffering alongside you while the pipeline breaks on a Friday afternoon.

When a request is incomplete, the model has to fill in the gaps. That is when the guesses begin. Several questions may remain unanswered:

• Who is the answer for?
• What is the goal?
• What level of depth is expected?
• What should be avoided?
• How will the output be used?
• Which technologies, rules, and limitations matter?

Consider an example from software development.

Vague request:

Create a user API.

This request could produce a REST API or GraphQL API, with JWT authentication or without authentication, using Node.js, Java, or Python, with a relational database or an in-memory database, with a layered architecture or a minimalist architecture—the menu is extensive.

A more useful version would be:

I want a design proposal for a user REST API in Java 21 with Spring Boot.
Context: the application already uses PostgreSQL and JWT authentication.
The API must support user creation, lookup by ID, paginated listing, and user deactivation.
Constraints: do not include physical deletion; do not use libraries beyond those already common in Spring Boot; account for unique email validation.
Response format: list endpoints, input payloads, expected responses, business rules, and acceptance criteria.
If any information is missing, list questions before making assumptions.

The difference is not about 'convincing' the AI with a secret phrase. It is about removing ambiguity.

On the other hand, there is a trade-off: more context tends to improve the relevance of the answer, but excessive, disorganized, or irrelevant context can confuse the task. A prompt made up of several paragraphs containing history, opinions, loose logs, and mixed requirements can become a messy drawer.

Sometimes, the best prompt is the one that provides what is necessary—neither less nor much more.

Prompt engineering in practice: a simple structure

A practical way to improve your prompts is to use a checklist. Not as a rigid formula—because an overly rigid formula becomes bureaucracy by another name—but as a reminder of what often influences the quality of the answer.

Goal

Clearly state what you want to obtain.

Instead of:

Can you help me with this?

Prefer:

Explain this error and propose diagnostic steps before suggesting fixes.

Or:

Review this text to make it clearer for nontechnical people without changing its meaning.

The goal defines the type of help you expect. Diagnosing, summarizing, reviewing, comparing, planning, and explaining are different tasks. When the goal is not stated, the model tends to choose a direction on its own.

Context

Include the information necessary for the task: scenario, audience, technology, available data, and decisions that have already been made.

For example:

I am investigating a failure in an integration test in a Java application with Spring Boot.
The test should return HTTP 201 when creating a user, but it is returning 400.
Unique email validation was added recently.
I want prioritized hypotheses, not a direct fix yet.

Context does not mean dumping everything. It means giving the model the relevant pieces of the puzzle.

One important caution: do not send passwords, tokens, personal data, customer information, confidential excerpts, or proprietary code without authorization and without understanding the policies of the tool you are using. A good prompt does not make up for leaking sensitive information.

Role or perspective

Asking for a role can help when it defines the type of analysis you want.

Example:

Analyze this as someone reviewing Java code to identify risks related to readability, maintainability, and unexpected behavior.

This is better than simply saying:

Act as an expert.

'Act as an expert' by itself does not solve a lack of context. It is like asking someone to 'be senior' without explaining the problem, the system, the constraints, or what needs to be decided. It may sound impressive, but it does not deliver much.

Use roles to indicate a perspective, not as a command of authority.

Constraints

Constraints prevent solutions that are incompatible with reality.

Examples:

Do not use external libraries.
Consider Java 21.
Keep the solution within two classes.
Do not propose changes to the public API.
Prioritize alternatives with the lowest impact on the existing code.

Constraints are especially useful when many solutions are possible. They also help prevent answers that look great in an idealized project but are impractical in your context.

Output format

Requesting a format makes the answer easier to use and review.

Examples:

Respond with: hypothesis, evidence in the code, risk, suggested fix, and recommended test.

Or:

Organize the answer in a table with the following columns: problem, impact, priority, and suggested action.

Or:

Respond in numbered steps, starting with checks that do not change the code.

Format is not merely a cosmetic detail. It guides the reasoning and makes the answer more auditable. When the output is organized, it is easier to see what is an assumption, what is a recommendation, and what needs to be validated.

Examples

When tone, format, or quality standards are difficult to explain, provide an example.

For example:

Use this response style: - 'Confirmed': information present in the text. - 'Hypothesis': a possible but unproven interpretation. - 'Open question': something that needs to be validated.

Examples provide substantial guidance for the output. The trade-off is that they can also limit better alternatives. If you provide an overly rigid example, the model may copy the pattern even when another format would be more appropriate.

Quality criteria

Explain how you intend to evaluate the answer.

Examples:

If information is missing, list questions before assuming details.

Distinguish facts, hypotheses, and recommendations.

Point out risks and necessary tests before suggesting an implementation.

Do not invent libraries, APIs, or references. If you do not know, say that you need to verify.

Quality criteria change the conversation. Instead of asking only for an answer, you are asking for an answer that can be reviewed.

This matters because a polished answer can still be wrong. Explicit criteria help reduce that risk, but they do not replace validation.

From a vague request to a useful prompt: practical examples

The best way to understand prompt engineering is to see the difference between an open-ended request and a clearer instruction. The examples below are not universal 'ready-to-use prompts'. They are reasoning models to adapt to your context.

Development: investigating an error

Initial request:

Why is my test failing?

Problems with this request:

• it does not show the error;
• it does not show the expected behavior;
• it does not provide the language, framework, or environment;
• it does not request a specific type of help;
• it encourages guessing.

Revised version:

I am investigating a failing integration test in a Java 21 application with Spring Boot.
Expected behavior: when a valid request is sent to create a user, the API should return HTTP 201.
Current behavior: the test returns HTTP 400.
Recent change: we added unique email validation.
The test snippet, payload, and error message are below.
I want you to propose prioritized hypotheses. For each hypothesis, indicate: evidence, how to verify it, and a possible fix.
Do not propose code changes before listing the checks.

How to review the output:

• try to reproduce the problem;
• validate each hypothesis;
• check whether the suggestion respects the project's architecture;
• do not apply a fix without understanding the cause;
• run the tests afterward.

An LLM can speed up an investigation, but it does not run the system for you. At least not in this scenario. Thankfully—someone still needs to press the red button responsibly.

Writing: reviewing a technical message

Initial request:

Improve this message.

Revised version:

Review the message below to communicate an incident update to nontechnical people.
Context: there was login instability between 10:00 and 10:25. The service has been restored. We do not yet have a confirmed root cause.
Constraints: do not invent a cause; do not minimize the impact; separate current impact from next steps.
Format: title, summary, impact, current status, and next update.
Tone: clear, direct, and without defensive language.

This type of prompt is useful because it avoids a common mistake: the model may 'polish' the message too much and end up stating things that have not yet been confirmed.

When dealing with an incident, clarity matters more than embellishment. If the root cause has not been confirmed, the text needs to say so. If there was an impact, the text should not hide it. The prompt helps make these boundaries explicit.

Summarization: turning long content into study material

Initial request:

Summarize this text.

Revised version:

Summarize the text below as study material for someone who is new to the topic.
Include: - main concepts; - cited examples; - terms that deserve further review; - open questions; - a list of 5 self-assessment questions.
Limit the answer to approximately one page.
Do not add information from outside the text.

How to review the output:

• compare it with the original material;
• check whether important nuances were omitted;
• make sure the model has not added its own interpretations as if they were facts;
• use the summary as support, not as a replacement for reading.

Summaries are useful, but they can flatten complex ideas. Sometimes, the detail left out was precisely the most important one.

Planning: breaking down a task

Initial request:

Plan this feature.

Revised version:

I want to break a small delivery into implementation steps.
Context: we need to add the option to deactivate users without deleting records from the database.
The application already has creation and lookup endpoints.
Generate a proposal with: - technical steps; - dependencies; - risks; - open questions; - suggested tests.
Do not estimate time. Do not assume changes to screens, because we do not yet know whether there will be an interface.

This type of answer can help start a conversation with the team more effectively. However, priorities, effort, and the actual sequence depend on the team, product, and existing system context.

Here, the main benefit is not outsourcing planning. It is creating an initial structure for a better discussion: what still needs to be decided, where the risks are, and which tests can protect the change.

Analysis: interpreting data or results

Initial request:

Analyze these numbers.

Revised version:

Analyze the data below based only on the information provided.
I want you to: - describe observable trends; - distinguish strong conclusions from hypotheses; - point out gaps in the data; - identify possible biases; - state which conclusions cannot be supported.
Do not invent external context.

This care is essential because LLMs tend to complete narratives. If you provide an incomplete table, the model may produce a plausible explanation without sufficient evidence.

In these cases, a good prompt does not merely ask for 'an analysis'. It sets boundaries: what can be concluded, what is a hypothesis, and what still requires better data.

A practical cycle for writing, testing, and reviewing

Prompt engineering is iterative. It is more like refining a specification, a search, or an exploratory test than writing an enchanted password.

A simple cycle can help.

Write the first version

Start with the goal and minimum context.

For example:

I want to review this documentation excerpt to make it clearer for junior developers.
Keep the instructional tone.
Point out ambiguities before rewriting.

Do not try to anticipate every possibility right away. A first version that is good enough already allows you to learn from the answer.

Inspect the answer

After receiving the answer, ask:

• Does it meet the goal?
• Did it respect the constraints?
• Did it invent information?
• Did it explain its assumptions?
• Does the format make the result easier to use or validate?
• Was any important information missing?

This is where many people lose quality. The answer arrives polished, formatted, and confident; the temptation is to copy it and move on. But well-written text is not synonymous with a correct answer.

Refine the instruction

Use what went wrong to improve the prompt.

Examples of refinements:

Prioritize alternatives with the lowest impact on the existing code.

Do not propose changes to the public API.

Before answering, list missing information that could change the recommendation.

Separate 'what we know' from 'what needs to be verified'.

Refining is not 'arguing' with the tool. It is adjusting the specification.

If the answer was generic, it may be missing context. If it was too long, it may be missing a constraint. If it invented details, it may need quality criteria and validation requirements. The prompt improves when you observe the type of error that appeared.

Validate outside the conversation

This is the least glamorous and most important part.

Validate with:

• executable code;
• automated tests;
• official documentation;
• primary sources;
• original data;
• human review;
• criteria defined by the team.

Asking the LLM itself to 'confirm whether it is correct' is not independent validation. It may repeat the error with even more conviction. That is the conversational equivalent of asking your bug whether it is sure it is a bug.

Tools can support analysis, scenario generation, and investigation, but they still require technical validation. The final decision must consider the real system, the team's constraints, and the impact of the change.

Limits and precautions when using LLMs at work and while studying

LLMs are useful, but they have important limitations. The problem is that they can make mistakes in highly convincing prose.

Hallucinations and verifiability

An LLM may invent:

• APIs that do not exist;
• incorrect parameters;
• library behavior;
• references;
• justifications;
• details about code it has not seen.

Therefore, ask for verifiable answers.

Example:

If you cite an API, indicate how I can verify it in the official documentation.
If you are not sure, signal uncertainty instead of stating it as fact.

Even so, do not delegate the verification. Run the code. Consult the documentation. Check the repository. Test the hypothesis.

Ambiguity

If the request allows for different interpretations, the answer may take an unexpected direction.

A good practice is to ask for clarifying questions:

If there is not enough information for a safe recommendation, ask up to 5 questions before answering.

This is especially useful in architecture, requirements, data analysis, and product decisions.

When the model asks questions before answering, the conversation may become a little slower. In return, the answer tends to align better with the real problem. This is a good trade-off when a wrong assumption could be costly.

Sensitive data

Avoid including:

• passwords;
• tokens;
• API keys;
• personal data;
• customer information;
• trade secrets;
• confidential code;
• logs containing sensitive data;
• internal documents without authorization.

Before using a tool at work, understand the policies of your organization and of the tool itself. If you do not know whether you may send something, treat it as if you may not.

A well-structured prompt does not justify exposing sensitive information. When necessary, remove or anonymize data before asking for help—and do so in accordance with your organization's rules.

Responsibility for the decision

Use LLMs to:

• explore options;
• organize ideas;
• generate drafts;
• review clarity;
• raise hypotheses;
• create checklists;
• compare alternatives.

But be careful when using answers in critical decisions, especially in security, data, healthcare, finance, legal matters, or production software. Responsibility remains human and organizational.

The tool can help you think. It should not be the autopilot for decisions that require context, responsibility, and validation.

Final checklist for your next prompt

Before sending your next prompt, review:

• What result do I want?
• What context is essential?
• For whom and for what use will this answer be produced?
• Which limits or constraints must be respected?
• In what format should the answer be delivered?
• Would an example help reduce ambiguity?
• How will I verify the answer before using it?

A compact prompt could follow this model:

I want [goal].
Context: [relevant information].
Audience/use: [who will use it and for what].
Constraints: [limits, technologies, tone, scope].
Format: [expected structure].
Quality criteria: [how to evaluate].
If information is missing, [ask before assuming / state assumptions explicitly].

Better prompts do not depend on secret words. They depend on clear intent, context, and criteria.

To get started, choose a routine task: review a message, summarize a text, investigate an error, or plan a small delivery. First, make a vague request. Then rewrite it using the structure from this article. Compare the answers. This contrast usually teaches more than memorizing any list of 'perfect prompts'.

Next steps

• Choose a real task that you would already do today with support from an LLM.
• Write a first version of the prompt using a goal, context, constraints, and format.
• Review the answer for assumptions, gaps, and unverifiable points.
• Refine the prompt once and compare the result.
• Validate outside the conversation before using the answer.

If you enjoy discussing development practices, quality, and the responsible use of AI in everyday work, join the SCCB community.