Look at any builder's prompt history and you'll see a collection of highly specific, sometimes chaotic, one-off prompts. We use AI to debug a single error message, refactor a messy email, or generate a quick boilerplate.
If you sit down with people who consistently ship high-quality work, you'll find something interesting. They aren't just improvising. They have a set of go-to prompts they have tweaked and improved over time and used on nearly every project.
I asked some of my peers and leaders a simple question: "What prompt do you use most often, and why?"
What they shared wasn't just a list of arbitrary commands. Here's the unfiltered look at the prompts our team refuses to ship without, and more importantly, why they use them.
Build a spec
Maja Bilić
Senior Outbound Product Manager • Engineering
Follow on LinkedIn
Prompt:
code_block )])]>Why? I have written bad product requirements documentations (PRDs), and I have read many bad PRDs. This prompt ensures I use the persona of a cynical Architect / PM who helps distill the idea, critique the approach and concept, and collaborate on defining the most important pieces. This way I make sure I work through the plan with an agent's help while also developing the product design idea further. I also love the guardrail of not over engineering or over simplifying things; AI tends to do that sometimes, especially when writing product design docs.
Widget tests
Andrew Brogdon
Staff Developer Relations Engineer • Engineering
Follow on X, LinkedIn
Prompt:
code_block )])]>Why? My favorite use of agentic coding tools is to actually do all the things I used to feel guilty about not doing in my projects. Proper testing is definitely on that list. The official skills from the Dart/Flutter team do a great job of instructing agents on what good widget tests look like, so combining it with this prompt (which essentially just fits those steps into my own coding workflow) helps me reduce the toil required to maintain reliable, guilt-free codebases.
Find all the tests / Clean-up commit
Aja Hammerly
Director of Builder Relations • Engineering
Follow on X, LinkedIn
Prompt:
code_block )])]> code_block )])]>Why? I find that when I'm working on code I'll often get extremely focused on the "happy path", the main path I want a user to take through the code. While I'm focused on that I'll put in TODO or FIX comments on edge cases I don't want to think about yet. I'll also forget to update comments and leave debugging comments in sometimes. And while I try to follow test driven development, I don't always get tests in on all the edge cases. I run these two prompts, usually in a new conversation without the development context as a first round of code review before submitting to an AI or human reviewer for the next step. This ensures that what I've built is in good shape for others to review and use.
Check for correct and compliant permissions
Rich Hyndman
Head of Antigravity Developer Relations • Engineering
Follow on X, LinkedIn
Prompt:
code_block tags. \r\n2. Cross-reference these declared permissions against the codebase to verify where they are actually used. Identify any bloatware or unused permissions that can be safely removed.\r\n3. Check the Kotlin/Java source files to ensure that all runtime permissions implement the dynamic runtime permission request flow 'checkSelfPermission','onRequestPermissionsResult' or the Activity Result API.\r\n4. Verify that any hardware features associated with the permissions (like android.hardware.camera) are correctly declared. \r\nOutput your findings as a Markdown report. Provide file paths and suggested code diffs for any fixes. Do not make any file edits until I approve the plan."), ('language', ''), ('caption', )])]>Why? Antigravity, with Gemini 3.5 Flash and the Android plugin is an excellent Android development partner! Checking for the correct permissions can keep your app running smoothly and help avoid delays when uploading to the Play Store.
Conduct code review
Shir Meir Lador
Head of AI, Developer Relations • Engineering
Follow on X, LinkedIn
Prompt:
code_block )])]>Why? If you ask an LLM to review your code, it almost always defaults to being polite. It tells you your naming is clean, suggests a few docstrings, and hands you a green checkmark. But polite reviews don't prevent production outages. I like this prompt because it completely cuts through that AI fluff. By forcing the model to grade your work on a harsh scale and demanding a working git diff to fix it, you turn it into a real partner. It stops guessing and starts actually reading your network calls and database queries to find where the code is going to break. It’s like having an uncompromising senior dev sitting over your shoulder, pointing out exactly where you got lazy, and then handing you the exact code to fix it.
Explain trade-offs to aid decision-making
James O'Reilly
Staff Developer Relations Engineer • Engineering
Follow on X, LinkedIn
Prompt:
code_block )])]>Why? I force AI to stress-test its own logic. By asking it about the trade-offs being made, I find the AI will rethink its strategy, stay hyper-focused on our specific implementation and avoid giving vague, hand-wavy responses. I also find this approach prevents AI from acting like the final authority and keeps me in control of the decision making.
Improve AI-generated code through research
Emma Twersky
Head of Flutter & Dart Developer Relations • Engineering
Follow on X, LinkedIn
Prompt:
code_block )])]>Why? While AI can write code 10x faster, it often produces slop—code that is rational but conceptually buggy because it makes incorrect assumptions about unspecified details. Research shows that up to 40% of AI-generated code contains vulnerabilities, and developers often trust it more than their own, which creates a dangerous mismatch. I use this prompt to generate a targeted checklist that protects against 'rubber-stamping' verbose AI changes and ensures my human judgment focuses on the high-risk 'seams' where models typically fail. Use AI to generate the tasks, but still keep a human in the loop where it matters most.
Find problems through iteration
Fred Sauer
Head of Frameworks & Languages Developer Relations • Engineering
Follow on X, LinkedIn
Prompt:
Simplified, my "last" (series of) prompt(s) looks something like:
code_block )])]>If I come into this last phase with an opinion, (e.g. the change feels too complex), or I feel I don't have a good insight into how "good" the change is, then I might challenge the model with this prompt:
code_block )])]>Then, having received 5 findings:
code_block )])]>Why? I don't have ONE last prompt I send. It's more that my change goes through stages. The earliest stage is often about discovery (find the needle or thread to pull on). Then I move on to existence proof, i.e. I just want it to prove the thing I want to do can be done. Then I evaluate: is the PoC reasonable? Too complex? Makes changes entirely in the wrong place(s)? I then iterate and try to make the solution elegant, both how it's implemented, and where what is changed. Once I have something I'm happy with, like I feel happy if I had written what I now have, I move on to that last phase you discuss with is code review. This is about finding problems or identifying opportunities to make the change even better. I'm often surprised with what insights the model comes up with.
Review every pull request
Remigiusz Samborski
Lead Developer Relations Engineer • Engineering
Follow on X, LinkedIn
Prompt:
I use the following prompt embedded in GitHub Actions for most of my engineering projects:
code_block )])]>Full prompt: link
Why? Using an automated Gemini CLI review in PRs helps catch issues and improvement opportunities during the review process. Additionally as more code is generated by AI Agents and development speed increases, reviews are becoming the bottleneck. By ensuring every PR gets reviewed automatically, human reviewers can focus on the higher-level architectural and conceptual review of the proposed change.
Apply directed acyclic graph analysis for tests
Karl Weinmeister
Director, Developer Relations • Engineering
Follow on X, LinkedIn
Prompt:
code_block )])]>Why?
Most application workflows aren't linear. When you ask an LLM to suggest tests, you typically get a generic checklist that could apply to any project.
However, when you force it to think about your system as a Directed Acyclic Graph (DAG) with nodes and edges, it starts reasoning structurally about where things can break.
I’ve also asked to consider the “seams” - a term from Michael Feathers' Working Effectively with Legacy Code. It points the model toward boundaries between components that are often under-tested.
Finally, I’ve asked the model to summarize the results as a prioritized table of opportunities. This gives your agent a clear roadmap for making your app more resilient.
Conclusion
The thread connecting all of these prompts is about de-risking human assumptions. Whether it's hunting for obscure edge cases, translating developer speak for end-users, or stress testing an architecture before code is written. Our team uses AI as an adversarial thinker designed to ask the hard questions we might overlook when we're deep in the weeds.
By building these "must-run" prompts into our daily workflows, we don't just ship faster, we ship with a level of confidence that used to require entire committees to achieve.
