What Is Prompt Engineering for Developers?

The prompt looks polished. The answer looks plausible. The test is still wrong.

That is the situation many beginners meet when they ask an AI assistant to write code. You are working through a Python assignment at a community college, preparing a small portfolio project after work, or reviewing a support script. You ask for a function that calculates an average. The assistant returns code, an explanation, and a test. Everything looks finished—until the input list is empty.

def average(numbers):
    return sum(numbers) / len(numbers)

What should average([]) do? Raise an error? Return None? Return 0? The model cannot choose that product or teaching rule for you. This is where prompt engineering for developers becomes useful: not as a collection of magic phrases, but as a way to make behavior explicit enough to inspect.

The first prompt fails before the code does

A beginner might write:

Write a Python function to calculate the average of a list.

The request names a task, but not the contract. It does not say what an empty list means, whether inputs are integers or floats, whether a package is allowed, what output format is expected, or which tests would count as evidence.

A more useful request is not necessarily longer for its own sake. It is more specific about the decisions that matter:

Review the Python function below.

Task:
- Explain what it does for a non-empty list.
- Identify the behavior for an empty list.
- Do not change the function yet.

Constraints:
- Use the Python standard library only.
- Keep the function name `average`.
- The caller expects `None` for an empty list.

Return exactly three sections:
1. Cause
2. Minimal fix
3. Tests

<code_to_review>
def average(numbers):
    return sum(numbers) / len(numbers)
</code_to_review>

The improvement is not the presence of XML-looking tags. The improvement is that the request separates the task, context, constraints, output shape, and code under review. OpenAI’s prompt-engineering guidance recommends clear instructions, relevant context, and examples or output requirements when they reduce ambiguity. Anthropic’s prompting guidance similarly recommends descriptive tags when a prompt mixes instructions, context, examples, and variable input.

Tags are optional. The boundary is not. A model should be able to tell which text is a rule, which text is data, and which text is an example.

Before asking for a fix, decide what “correct” means

For this exercise, the contract is:

assert average([2, 4, 6]) == 4
assert average([1.5, 2.5]) == 2.0
assert average([]) is None

Now the assistant has a behavior to implement and a behavior to preserve. A possible minimal fix is:

def average(numbers):
    if not numbers:
        return None
    return sum(numbers) / len(numbers)

The code may be correct for this contract, but the prompt did not prove that the list contains only numeric values. What should happen for average([2, "4"])? Should the function reject the input, coerce the string, or let Python raise a TypeError? That question belongs in the requirements or tests, not in a decorative prompt phrase.

A prompt can request tests, but it cannot make an unchosen requirement real. This is why the pytest documentation is useful alongside an AI assistant: tests turn the intended behavior into something you can run, not merely something the answer claims.

Maya’s review: one answer, three decisions

Imagine Maya, a beginner building a small ticket-reporting script for a class project. Her instructor has asked for a function that groups completed tasks by date. Maya’s first prompt is broad:

Write a Python function that groups completed tasks by date.

The returned code might be perfectly reasonable and still be wrong for her assignment. The assistant does not know whether “date” means UTC or the user’s local calendar day, whether incomplete tasks should be ignored, whether missing timestamps are valid, or whether the input list may be changed.

Maya rewrites the request as a decision record:

Goal: group completed tasks for a class ticket report.

Input:
- A list of dictionaries.
- Each dictionary has `completed` and may have `completedAt`.

Rules:
- Include only tasks where `completed is True`.
- Ignore tasks where `completedAt is None`.
- For this first version, group by the UTC date written in an ISO timestamp ending in Z.
- Do not mutate the input list.
- Use the standard library only.

Output:
- Return a dictionary keyed by YYYY-MM-DD.
- Under each key, keep the original task dictionaries.

Before writing the final code, list two assumptions and three tests.

This version gives the assistant something inspectable. It also gives Maya something to challenge. The phrase “UTC date written in an ISO timestamp ending in Z” is a choice, not a universal truth. If a product manager later says “show each user’s local day,” the implementation and tests must change.

Do not let the example hide the timezone decision

A compact implementation might be:

def group_completed_tasks_by_date(tasks):
    groups = {}
    for task in tasks:
        if not task["completed"] or not task.get("completedAt"):
            continue
        date = task["completedAt"][:10]
        groups.setdefault(date, []).append(task)
    return groups

Now ask the assistant a narrower question instead of asking it to rewrite everything:

Explain which calendar date this implementation uses for a timestamp ending in Z.
Do not change the code. Give one timestamp near midnight that could expose a
UTC-versus-local-time difference, then state which requirement we must decide.

This is a better prompt because it asks for an explanation and a test idea, not an unreviewable replacement. The model can point out the assumption; Maya still decides whether it matches the project.

In a support, QA, or junior development setting, this distinction matters. The Bureau of Labor Statistics describes software developers and QA analysts in terms of analyzing needs, designing solutions, testing, and identifying problems. A prompt that forces assumptions and tests into view is closer to that work than one that merely requests “clean code.”

Examples are steering, not proof

Suppose Maya wants a predictable response. She provides a miniature format:

Use this response shape:
Cause: one paragraph
Assumptions: two bullets
Minimal fix: one code block
Tests: exactly three assertions

Examples can help a model follow a shape, especially when a developer needs a structured answer that can be reviewed or parsed. They do not establish that the code is correct. A model can follow the requested headings while inventing a test, omitting an important case, or selecting the wrong runtime API.

When a prompt includes repository rules, code, sample data, and a response schema, use explicit separators such as <requirements>, <code>, and <expected_output>. When the request is simply “explain this one line,” adding a miniature markup system may add more ceremony than value.

Prompting for learning is not the same as prompting for delivery

The best request changes with your goal.

A learner in a community-college programming course may need an explanation and a chance to make the prediction. A person preparing a portfolio may need a diff, tests, and a README note. A support or QA trainee may need a reproducible input and expected versus actual output. The word “prompt” stays the same; the evidence you need is different.

For a local study option, the New York Public Library’s TechConnect listings have included introductory Python classes. A listing is a place to look, not proof that a specific class is currently open or that it leads to employment. The learning decision is still yours: what can you practice, run, and explain after the session?

One change at a time is a better prompt experiment

Suppose the assistant returns a correct-looking fix but omits the requested empty-list assertion. Do not discard the entire conversation and paste a completely different mega-prompt. Change one variable:

The handling of an empty list is correct, but the response omitted the tests.
Return only these sections: Cause, Minimal fix, Tests.
Include exactly:
assert average([2, 4, 6]) == 4
assert average([]) is None

Now you can compare the result. Did the format improve? Did the assistant change the code unnecessarily? Did it add a test that does not run in your project? Iteration turns prompting into a small experiment: modify the instruction, observe the output, and keep the requirement that mattered.

The same discipline appears in debugging. The Vandutz traceback guide treats a failure as evidence to reproduce and test. The Vandutz guide to AI-assisted debugging adds a boundary: ask for hypotheses, apply the smallest patch, and run the failing test yourself. Prompt engineering should connect to that workflow, not replace it.

What a well-written prompt still cannot decide

No prompt can tell an assistant whether a business rule is approved, whether customer data may be shared, whether a dependency is allowed, or whether a test covers the risk that matters. It cannot turn a simulated assignment into professional experience.

Keep secrets, private customer records, proprietary source code, and production logs out of a personal AI conversation. If you need help, reduce the example to the smallest safe reproduction and replace sensitive values with placeholders. The Vandutz guide to sharing context with coding assistants explains why context minimization is part of the technical task, not an optional cleanup step.

Also avoid requesting hidden internal reasoning as if it were a quality guarantee. Ask for a concise explanation, assumptions, checks, and tests that you can evaluate. Those are useful artifacts. A long answer is not automatically a reliable one.

A short market note: what beginners should take from the 2026 signals

Recent U.S. reports suggest that AI literacy is becoming part of early-career conversations, but they do not show that a prompt-writing trick guarantees a job. NACE’s 2026 Job Outlook Spring Update reports growing employer expectations around AI skills for early-career talent. The BLS discussion of AI and employment projections describes software developers using AI to develop, test, and document code, while the O*NET software developer profile includes testing, documentation, and validation as part of the occupation.

The useful conclusion for a beginner is narrower: practice writing requirements, asking for assumptions, creating tests, and explaining trade-offs. Those habits can make a project easier to review in a classroom, a portfolio conversation, QA exercise, support workflow, or development team. Prompt engineering is valuable when it improves the quality of the decision around the code—not when it hides the decision behind a fluent answer.

Keep this five-line prompt card

Goal: What behavior am I trying to achieve?
Context: What code, data, runtime, and audience matter?
Constraints: What must not change or be exposed?
Output: What exact shape should the answer have?
Evidence: Which tests, examples, or checks will decide whether it works?

Before you ask an assistant for code, fill in the card. If you cannot answer the evidence line, you are probably not ready to ask for a final implementation. Ask for clarification, a comparison, or a test idea instead.

That is the difference between a prompt that asks for code and a prompt that creates something you can actually inspect.

Alex Carter

Alex Carter is the editorial name behind Vandutz Academy, a programming blog for beginners. Alex reviews and tests the examples and explanations published on the site, with a focus on making Python, JavaScript, web development, and developer tools easier to understand.