What We Can Learn From Google Engineers’ Indispensible Prompts

Google Cloud's developer relations team asked ten of its engineers and leaders which prompt they refuse to work without, and the responses, published in June 2026, converge on using AI as an adversarial second opinion rather than an agreeable assistant. Techniques include Maja Bilić's skeptical persona prompt for building specs before code and Andrew Brogdon's testability audit prompt, both demonstrated with original examples for a task-tracker API.

What We Can Learn From Google Engineers’ Indispensible Prompts Hey, Google Engineers: What prompt do you personally refuse to work without, and why? Most people's prompt history looks like a junk drawer. A one-off request to explain an error message, a quick " clean this up ," a boilerplate generator used once and forgotten. In June 2026, Google Cloud's developer relations team published something different: they asked ten of their own engineers and leaders one specific question: what prompt do you personally refuse to work without, and why? What came back wasn't a list of clever phrasings. It was ten different engineers, independently arriving at the same underlying move: using AI as an adversarial second opinion rather than an agreeable assistant. That distinction is the entire subject of this article. Below are ten techniques pulled from that piece, each one explained, attributed to the engineer who shared it, and then rebuilt as an original example prompt you can actually use — not copied verbatim, but reconstructed to show the same pattern at work. Every example applies to one running project: a small task-tracker REST API, so the techniques build on each other instead of resetting to a new hypothetical every section. Building the Spec Before Any Code Exists Maja Bilić, a Senior Outbound Product Manager at Google Cloud, doesn't start with code; she starts by making the model argue with her. Her technique assigns the model a specific, skeptical persona a cynical principal architect and technical PM , explicitly forbids it from writing code, and has it list the key technical, UX, and architectural considerations for the idea before asking targeted questions on each one. Once that back-and-forth is done, the model turns the answers into an actual requirements document and implementation plan, with an instruction not to over-engineer or oversimplify either direction. The reasoning is worth sitting with: a model asked to help " plan a feature " will often just agree with the first framing you give it. A model asked to critique a concept from a skeptical persona has to generate actual objections first, and those objections are usually where the real planning value is. Applied to the task tracker: Act as a skeptical principal architect reviewing a proposed feature, not writing code yet. I want to add recurring tasks to a task-tracker API, tasks that regenerate on a schedule daily, weekly, custom RRULE . Do not write any code. List the top 5 technical, data-model, and UX considerations this feature raises. For each one, ask me the specific questions you need answered before this could be built responsibly. Once I've answered all of them, draft a short spec and implementation plan. Don't over-engineer this for scale we don't have, and don't oversimplify by ignoring timezone or edge-case handling. Making Testing Non-Negotiable Andrew Brogdon, a Staff Developer Relations Engineer, uses a prompt that treats testing as something to audit rather than generate. Rather than asking for tests directly, his pattern has the model first examine the codebase to find which parts of the UI or logic aren't properly covered, judge whether the existing code is even written in a testable way dependencies injected, domains loosely coupled , and only then build and execute an actual testing plan — moving one confident step at a time rather than rushing straight to output. The insight underneath this one is simple but easy to skip: asking directly for tests gets you tests for whatever's easiest to test, not what actually needs coverage. Auditing testability first catches the gap between " tested " and " well-tested. " Applied to the task tracker: Partner with me on improving test coverage for this task-tracker API. First, examine the codebase and identify which endpoints and business logic aren't properly tested. Then assess whether the current code is actually written in a testable way, are external calls injected or hardcoded, is the scheduling logic isolated from the HTTP layer. Build a prioritized testing plan based on what you find, tell me what's already covered, then implement the missing tests. Don't skip ahead to writing tests until you're confident in your assessment of what's actually missing. Running the Two-Prompt Cleanup Pass Aja Hammerly, Director of Builder Relations, runs two separate, narrow prompts before handing code to review — deliberately in a fresh conversation with no development context attached. The first asks the model to run the existing tests, then specifically hunt for missing edge cases and race conditions. The second, run separately, looks for a different category entirely: unused code, leftover debug comments, comments that no longer match the code they describe, and unresolved TODOs — the kind of small, embarrassing residue that piles up while you're focused on the main path through a feature. Running these as two distinct prompts rather than one combined request matters more than it looks like it should. A single broad "review this" prompt tends to blend everything into a generic pass. Separating " what's structurally missing " from " what's sloppy leftover " gets sharper answers on both. Applied to the task tracker: Fresh conversation, no prior context Run the test suite for this project and identify any missing tests. Pay specific attention to edge cases empty recurrence rules, timezone boundaries and race conditions two requests updating the same task simultaneously . Write the missing tests. Same fresh conversation Look through this commit for unused code, leftover debug comments, comments that no longer match what the code actually does, unresolved TODOs, or anything else that shouldn't ship. List each one with a file and line reference. Running Domain-Specific Compliance Checks Rich Hyndman, Head of Antigravity Developer Relations, shared a highly specific Android permissions audit: locate every manifest file across build variants, extract the declared permissions, cross-reference them against actual usage in the codebase to find bloat, verify runtime permission flows are implemented correctly, and confirm any hardware-feature declarations line up. Crucially, the prompt ends with an explicit instruction not to make any edits until the plan is approved. The pattern generalizes well past Android. Any compliance or configuration surface — environment variable usage, API scope grants, IAM role assignments — benefits from the same shape: locate every declaration, cross-reference against actual usage, flag the gap, propose fixes, wait for approval before touching anything. Applied to the task tracker its API authentication scopes, in this case : Run a compliance check on this API's authentication scopes. Locate every place a required OAuth scope is declared route decorators, middleware config, API gateway rules and build a master list. Cross- reference that list against where each scope is actually checked in the code, and flag any declared scope that's never enforced, or any enforced check that isn't declared anywhere. Output a markdown report with file paths and suggested diffs. Do not make any edits until I approve the plan. Grading Your Own Code Like a Harsh Reviewer Shir Meir Lador, Head of AI Developer Relations, names a real problem directly: ask a model for a code review, and it usually defaults to polite — a compliment on naming, a suggestion for a docstring, a green light. Her fix is to assign a specific, demanding persona a strict principal engineer with zero tolerance for happy-path code , then force an actual letter grade A through F on production readiness, explicitly instructing the model not to hand out an A unless the code is genuinely robust across efficiency, resilience, and architecture. The prompt closes by requiring exact fixes, not just commentary. This is worth using specifically because of how well it exposes the gap between "this code looks fine" and " this code is fine ." A grading rubric with a real failing condition forces the model to actually look for what would break, rather than defaulting to encouragement. Applied to the task tracker: Act as a strict principal engineer doing a pre-production review. Zero tolerance for fragile, happy-path-only code. Grade my uncommitted changes A through F for production readiness, don't give an A unless it's genuinely robust. Specifically check for: redundant database queries or missing caching, silent failure points and missing error boundaries around the scheduler, and tight coupling between the recurrence logic and the HTTP layer. For every issue, explain exactly how it fails in production, then give me the git diff to fix it and earn that grade. Making the Model Defend Its Own Plan James O'Reilly, the post's author and a Staff Developer Relations Engineer, uses one of the shortest prompts on the list — and it's arguably the most important: after getting an implementation plan, ask the model to explicitly lay out the trade-offs of its own suggestion across performance, cost, security, and maintainability. The goal isn't more code; it's forcing the model to stress-test its own reasoning rather than letting its first suggestion stand unchallenged. This directly counters a specific failure mode of working with AI on technical decisions: it's easy for a model's confident, well-formatted plan to feel like a settled decision rather than one option among several. Making it list what it's trading away keeps a human in the actual decision seat. Applied to the task tracker: Explain the trade-offs of the recurring-tasks implementation plan you just proposed. Be specific about what we're giving up on performance, cost, security, and long-term maintainability compared to at least one alternative approach, so I can make an informed call instead of just taking your first plan as final. Turning Outside Research Into a Review Checklist Emma Twersky, Head of Flutter & Dart Developer Relations, points the model outward before it looks inward: research real-world security pitfalls, architectural mistakes, and subtle logic errors specific to AI-generated code in a given tech stack — drawing on developer forums, GitHub issues, and technical blogs — then convert those findings into a targeted manual review checklist for the highest-risk parts of the codebase. The reasoning behind this one carries real weight. A well-known 2022 study on GitHub Copilot — analyzing 1,689 generated programs across 89 security-relevant scenarios, found that roughly 40% contained a real vulnerability https://arxiv.org/pdf/2506.11022 — a finding that later, larger studies have continued to reinforce rather than overturn. AI-written code doesn't look wrong. It compiles, it passes a casual glance, and that's exactly what makes an external, evidence-based checklist more useful than a generic " review this for bugs " request. Research current security pitfalls and subtle logic errors commonly found in AI-generated FastAPI code, focusing on developer forums, GitHub issue trackers, and recent technical write-ups. Based on what you find, build a manual review checklist specifically for auditing this project's highest-risk areas: the scheduling/cron logic, webhook signature verification, and how task ownership is checked on update requests. Iterating in Stages, Not One Mega-Prompt Fred Sauer, Head of Frameworks & Languages Developer Relations, doesn't describe a single prompt so much as a staged workflow. Early on, in a discovery phase, he deliberately stays less specific — arguing that being too prescriptive early creates blind spots the model won't think to question. That's followed by a proof-of-concept pass just to confirm the idea is buildable at all, then refinement toward something he'd be satisfied to have written himself, and only at the end — in a fresh conversation for a genuinely new perspective — a final code review, iterated until the findings get boring, meaning there's nothing significant left to catch. The lesson generalizes past his specific steps: matching prompt specificity to the actual stage of the work — loose early, precise late — tends to catch more than either being vague the whole way through or over-specifying from the very first prompt. Applied to the task tracker, the final-stage prompt looks like this: Fresh conversation Code review the uncommitted changes. Identify any unhandled corner cases. Assess performance. Summarize findings. And after getting back a list of findings: Fix findings 2, 4, and 5. Leave the others, I've decided they're not worth the added complexity right now. Automating the Review With a Real Script Remigiusz Samborski, a Lead Developer Relations Engineer, takes this pattern furthest: instead of remembering to ask for a review, his team wires an automated review agent directly into GitHub Actions , so every single pull request gets a structured, adversarial review with zero chance of someone forgetting to ask. His actual production prompt runs through Gemini CLI as a GitHub Action, and the full version is public on GitHub https://github.com/google-github-actions/run-gemini-cli/blob/main/examples/workflows/pr-review/gemini-review.toml if you want to see the real thing. Here's a working version of that same idea built independently and tested end to end — a Python script that pulls the actual git diff and sends it through the same grading-rubric pattern from section 5, meant to run in CI on every PR: """ auto review.py Runs a structured, adversarial code review against the current git diff. Meant to run in CI on every pull request, so review happens automatically instead of depending on someone remembering to ask. """ import os import subprocess import sys import anthropic REVIEW PROMPT = """You are a strict, principal-level code reviewer with zero \ tolerance for fragile, happy-path-only code. Review the diff below and grade \ it A through F for production readiness. Do not award an A unless the code is \ genuinely robust. For each issue found, cover: 1. Efficiency: redundant calls, uncached lookups, wasteful queries. 2. Resilience: silent failure points, missing error handling, no fallback \ behavior for external calls. 3. Architecture: tight coupling, unclear separation of concerns. For every issue, explain concretely how it could fail in production, then \ give the exact fix. Output as a markdown report with a letter grade at the top. DIFF: {diff} """ def get diff - str: """Pulls the actual staged diff from git, falling back to unstaged.""" result = subprocess.run "git", "diff", "--staged" , capture output=True, text=True, check=True diff = result.stdout if not diff.strip : result = subprocess.run "git", "diff" , capture output=True, text=True, check=True diff = result.stdout return diff def review diff diff: str - str: """Sends the diff to the model and returns the markdown review.""" client = anthropic.Anthropic api key=os.environ "ANTHROPIC API KEY" response = client.messages.create model="claude-sonnet-4-6", max tokens=2000, messages= {"role": "user", "content": REVIEW PROMPT.format diff=diff } , return "".join block.text for block in response.content if block.type == "text" def main : diff = get diff if not diff.strip : print "No changes to review." sys.exit 0 report = review diff diff with open "review report.md", "w" as f: f.write report print report if name == " main ": main What this does: get diff shells out to git and grabs whatever's staged, falling back to unstaged changes if nothing's staged yet, so the script works whether it's run locally before a commit or in CI against a PR branch. review diff drops that raw diff into the same adversarial grading prompt from section 5 and sends it to the model, then pulls the plain text back out of the response. main ties it together, writing the review to a file so a CI step can post it as a PR comment, and exiting cleanly with no API call at all if there's nothing to review. Prerequisites and how to run it: - Python 3.9+ pip install anthropic - An ANTHROPIC API KEY set in your environment. - Locally, run python auto review.py after staging some changes with git add . In CI, the same script slots into a GitHub Actions step that runs on every pull request event, with the output posted as a comment via the GitHub API — the same end goal as Samborski's setup, just built from scratch here rather than reusing his exact configuration. Thinking in Graphs, Not Checklists Karl Weinmeister, Director of Developer Relations, closes the original list with the least conventional technique: instead of asking for a generic list of test ideas — which tends to produce the same boilerplate checklist regardless of the actual project — he has the model represent the application's workflow as a directed acyclic graph nodes and edges and reason structurally about where failures could propagate. He specifically asks it to weigh " seams " — a term borrowed directly from Michael Feathers' work on legacy code — meaning the boundaries between components that are usually under-tested precisely because no single component owns them. The output is a prioritized markdown table rather than a flat list. Applied to the task tracker: Model this application's workflow as a directed acyclic graph: request comes in, auth middleware, task-ownership check, recurrence-expansion logic, database write, webhook dispatch. Identify the highest-impact tests for individual components, and separately for the seams between them, the boundaries where two components hand off and neither one is clearly responsible for validating what crosses that boundary. Present your findings as a prioritized markdown table: seam, risk, and suggested test. Wrapping Up Line all ten of these up next to each other, and the pattern connecting them stops being subtle. None of these prompts exists to save typing, and none of them is about getting more code out of the model faster. Every single one exists to de-risk a human assumption — the assumption that the happy path is enough, that a first plan is the right plan, that a glance at a diff counts as a review. If you only adopt one thing from this article, make it section 5's grading rubric, since it's the fastest way to feel the actual difference between a model that's being polite and one that's genuinely working against your blind spots, and once that difference is visible, the rest of these techniques start making a lot more sense as variations on the same idea. is a software engineer and technical writer passionate about leveraging cutting-edge technologies to craft compelling narratives, with a keen eye for detail and a knack for simplifying complex concepts. You can also find Shittu on Shittu Olumide https://www.linkedin.com/in/olumide-shittu/