.env
file and pray for the best. I did this last October with a prototype, and within two hours, a bot had scraped my public repo and burned through $40 of credits because I forgot to set a quota. It happens.When you're using Gemini 1.5 Pro or Flash for heavy lifting in your codebase, the "just make it work" mentality is where the leaks happen. You need a setup that doesn't just generate code, but protects your infrastructure.
Stop hardcoding your secrets #
If I see api_key = "AIza..."
in a Python file one more time, I'll lose it. Use a secret manager or at least a strictly ignored .env
file.
First, install the necessary bits:
pip install -q -U google-generativeai python-dotenv
Then, structure your project like this. No exceptions:
project/
├── .env # ADD THIS TO .gitignore
├── .gitignore # MUST include .env
└── main.py
In your .env
:
GEMINI_API_KEY=your_actual_key_here
And in main.py
, pull it in cleanly:
import os
from dotenv import load_dotenv
import google.generativeai as genai
load_dotenv()
api_key = os.getenv("GEMINI_API_KEY")
if not api_key:
raise ValueError("Missing GEMINI_API_KEY. Did you forget the .env file?")
genai.configure(api_key=api_key)
Hardening the prompt to stop hallucinations #
Gemini for coding is fast, but it can get "creative" with library versions, suggesting methods that were deprecated three years ago. This isn't just a bug; it's a security risk if it suggests an outdated library with a known CVE.
The fix is strict system instructions. Don't just ask for code; tell it exactly what constraints to follow. I use a "Constraint Block" for every coding prompt.
Try this config for your model initialization:
model = genai.GenerativeModel(
model_name="gemini-1.5-pro",
system_instruction=(
"You are a senior security engineer. "
"1. Only use stable, current library versions. "
"2. Always implement input validation for any user-facing function. "
"3. Never suggest 'eval()' or 'exec()' unless specifically asked for dynamic execution. "
"4. If a library has a known security vulnerability, suggest the patched alternative."
)
)
This shifts the model from "helper" mode to "engineer" mode. The difference in output quality is massive.
LLM security best practices for data leakage #
The biggest fear with LLMs is sending PII (Personally Identifiable Information) to the cloud. If you're piping your database schema or logs into Gemini, you're playing with fire.
I built a simple masking utility last month to handle this. It's a basic regex wrapper, but it saves you from accidentally leaking a client's email address to the model.
import re
def mask_sensitive_data(text):
text = re.sub(r'[\w\.-]+@[\w\.-]+\.\w+', '[EMAIL_MASKED]', text)
text = re.sub(r'AIza[0-9A-Za-z-_]{35}', '[API_KEY_MASKED]', text)
return text
raw_code = "def notify(user_email): print(f'Sending to {user_email}') # email: [email protected]"
safe_code = mask_sensitive_data(raw_code)
If you're doing this at scale, check out PromptCube homepage to see how others manage their prompt versions and testing without exposing raw data in every single iteration.
Comparing Gemini models for dev tasks #
Not every task needs the "Pro" model. Using the wrong one either wastes money or gives you buggy code. I ran a quick test last Tuesday on a complex FastAPI refactor task:
| Metric | Gemini 1.5 Flash | Gemini 1.5 Pro |
| :--- | :--- | :--- |
| Latency (avg) | 1.2s | 4.8s |
| Logic Accuracy | 70% (missed edge cases) | 95% (caught race condition) |
| Token Cost | Extremely Low | Moderate |
| Best Use Case | Unit test generation | Complex architecture / Debugging |
Use Flash for the boring stuff (docstrings, simple tests). Use Pro when you're actually trying to solve a bug that's been haunting you for three hours.
Dealing with "Prompt Drift" in your workflow #
The wild part is that a prompt that works today might fail tomorrow because the model was updated. If your CI/CD pipeline relies on AI-generated code or tests, you're essentially building on sand.
To stop this, you need a versioned prompt library. Instead of scattering strings across your .py
files, store them as assets.
"Refactor the following function for O(n) complexity.
Maintain type hinting and add Google-style docstrings."
these from a file allows you to roll back if the model suddenly starts adding weird comments to your code. For those who don't want to build their own versioning system, exploring Prompt Sharing is a great way to see how the community structures these "stable" prompts for coding.
The "Human-in-the-Loop" Filter #
Never—and I mean never—pipe Gemini's output directly into a shell=True
subprocess call. That's a recipe for a disaster.
Here is the minimum viable security wrapper for executing AI-suggested code in a dev environment:
-
Sandbox: Run it in a Docker container.
-
Timeout: Set a strict 5-second timeout.
-
Read-Only: Mount your source code as read-only.
Example of a safer execution wrapper:
import subprocess
def execute_ai_code(code_snippet):
try:
result = subprocess.run(
["python3", "-c", code_snippet],
capture_output=True,
text=True,
timeout=5
)
return result.stdout
except subprocess.TimeoutExpired:
return "Code took too long to run. Possible infinite loop."
except Exception as e:
return f"Execution error: {str(e)}"
Integrating these checks into your larger Workflows ensures that your productivity doesn't come at the cost of your system's stability.
The goal isn't to make the AI perfect—it won't be. The goal is to build a cage around it so that when it inevitably hallucinates a non-existent library or suggests a risky shortcut, your app doesn't crash in production.
Next Can we actually migrate Hermes Agent skills to OpenCode without →
a library of Claude prompt techniques, with plenty of directly applicable cases.
All Replies （0） #
No replies yet — be the first!