Anatomy of a Senior Engineer's Prompt

Most prompts fail for the same reason: they describe a wish, not a job.

The model fills the gaps, picks an approach that you may or may not approve, and hands back something that technically satisfies the request.

So how do you write a prompt that gets you exactly the output you had envisioned, on the very first go?

Simple: you give the model the same things you would give a senior engineer: the problem, the context, the constraints, the evidence to inspect, the outcome you expect, and a clear definition of done.

To walk you through what we mean, we will share a prompt we recently used to fix a real problem for a client. Their Gemini bills were climbing because of repeated load tests, and they needed a way to keep testing at scale without continuing to incur the same API costs.

The Prompt

The prompt, in full

Our Gemini API costs increased significantly in recent months, especially due to the load tests (<path-to-load-tests-src-dir>) we have been running on our agentic AI application (<path-to-agent-codebase>) with 100s of concurrent users, with each user asking tens of analytical questions from the agent.

Our test suite, as well as the agent, runs in a Kubernetes cluster.

Now we want to run some more load tests, but without the extra Gemini API costs. Here's how I want to address this:

Build a stub Gemini API simulator that receives and processes all of the agent's LLM inference requests. The stub service will be deployed on the VM as a pod. Nothing should change in the agent. We should either update the CoreDNS or add an environment variable to make the stub service automatically receive the requests aimed at the Gemini API, from the agent.

Now here's the important bit: we will need to ensure that the stub service behaves in exactly, or as close as possible, to the real Gemini API endpoints. As in:

It should take the same amount of time that Gemini takes for the same type of queries
It should support different model types (and respond based on that model's average latency times)
It should produce similar kinds of responses for similar kinds of queries, and basically, from the agent's perspective, it should feel as if it's getting responses from the actual Gemini API and not a stub service.

To be able to model this service properly, you would need to:

1. Go through the agent's codebase (<path-to-agent-codebase>) to study how it talks to the Gemini API, what endpoints it invokes, which models it uses, what sort of response it expects, what parameters it looks for in the response, and so on.
2. You will run different kinds of analytical queries from the load test bank (<path-to-load-test-questions>) through the actual agent and see how the Gemini API responds live. This will give you an idea of the actual response structures, tokens, typical latencies, and everything. Make sure you test drive all the models.
3. You will understand how our load test suite works.
4. There are some JSON and log files that I captured during our last load test run. They are present here: (<path-to-load-test-output>). You will go through them to see how the Gemini API behaves during an actual load run. Make sure to focus on how the latencies differ across models, at different concurrency levels, and whether we get any failures/timeouts from the Gemini API during the run.
5. Understand how our stack is currently deployed in Kubernetes: <path-to-deployment-codebase>.
6. Read the rough notes doc (<path-to-runner-notes>) to get even more context on how and what commands I run to get the Playwright suite up and running on the target VM.
7. Collect any other information that may be useful.
8. Finally, design the stub service and implement it. Ensure it supports different kinds of concurrency levels. Ensure it scales just as well (not beyond) as the Gemini API. Make sure it can run in our Kubernetes cluster. Generate a deployment file for it with the necessary resource limits.

Definition of done

The stub service ready to ship, full with its code and deployment instructions.

Here’s what makes it work:

It Provides All the Context Needed to Know Where to Look

Six paths appear in this prompt: the agent codebase, the load test source, the question bank, the captured run output, the deployment repo, and a rough notes doc.

Each one tells the model exactly where to look for the information it needs.

That matters because if the model has to find the context itself, it may miss something important or waste time searching through the wrong places.

If you already know where the relevant information lives, include it in the prompt.

It Makes the Key Constraints and Non-Negotiables Explicit

“Nothing should change in the agent.”

That single line removes the most tempting shortcut on the table. The easiest way to redirect an agent’s traffic is to edit the agent, and the model would have done exactly that.

The prompt names the two acceptable mechanisms instead: update CoreDNS, or add an environment variable. It doesn’t pick between them, but it does fence off everything else.

If a constraint matters, state it clearly in the prompt.

It Explains the Business Problem, as Well as the Technical Task

The prompt starts with the business problem: Gemini API costs were rising because of load testing.

That context tells the model why the stub is being built and what it needs to achieve. It is not just building a generic mock; it is solving a specific cost problem without compromising the load tests.

Giving the model the “why” helps it make better decisions when the prompt does not cover every detail.

It Requires Investigation and Understanding Before Implementation Begins

Implementation is step 8 of 8. The first seven are all research.

Read the agent's Gemini integration.✓
Run live queries through every model and watch the real responses come back.✓
Study the load test suite.✓
Go through the captured run output, with specific instructions on what to look for: latency across models, behavior at different concurrency levels, failures and timeouts.✓

Then, and only then, build.

That sequence ensures the stub is based on how the real system actually behaves, rather than on assumptions about how it should behave.

It Spells Out the Exact Behavior Required Instead of Giving a Vague Build Request

“Build a Gemini mock” is a request. What this prompt gives instead is closer to a specification.

It defines the behavior that matters: the same latency as the real API for similar query types, support for different models with different latency profiles, and response structures that match what the agent expects.

Writing those requirements out is a little like handing over pseudocode and asking for the algorithm. The shape of the solution is already clear.

It Gives Implementation Freedom While Staying Strict About the Required Outcome

The prompt never names a language, a framework, an HTTP library, or a latency-modeling strategy.

Similarly, for agent-stub connectivity, it offers two options (CoreDNS or an environment variable), and lets the model choose.

What it does make clear is the outcome: match Gemini’s latency, support all required models, leave the agent unchanged, run in Kubernetes, and include a deployment file with resource limits.

That gives the model freedom to make implementation decisions while keeping the requirements fixed.

It Treats Non-Functional Requirements as First-Class Requirements

"Ensure it supports different kinds of concurrency levels. Ensure it scales just as well (not beyond) as the Gemini API."

That parenthetical is especially important. A stub that is faster or more reliable than the real API could distort the results of the load test.

Resource limits get the same treatment. They’re stated as part of the deliverable, not left until deployment.

Performance, scaling behavior, and resource usage are not secondary requirements here. For a load testing tool, they are core to whether it works as intended.

It Finishes With a Concrete and Unambiguous Definition of Done

"The stub service ready to ship, full with its code and deployment instructions."

That makes it clear what needs to exist before the task can be considered complete: working code and everything needed to deploy it.

Without a definition of done, the model has to decide for itself where the task ends. That could mean stopping at working code without covering deployment.

A clear finish line makes the expected deliverables explicit..

Wrapping Up

It’s a pretty straightforward, plain-English prompt that gives the model enough context to do the job properly.

It takes a few extra minutes and some careful thought, but that investment can eliminate several rounds of corrections and review.

If you want the general version of this, we wrote it up in A Vibe Coder’s Guide to Prompting.