DEV Community

Leena Malhotra
Leena Malhotra

Posted on

Why Asking for Better Outputs Misses the Real Problem

#programming #ai #imagegen #nanobanana

Yesterday, I spent four hours debugging why Ideogram V3 kept generating inconsistent architectural renders. The whitepaper promised "improved spatial coherence." My outputs looked like they were designed by committee.

This isn't a model problem. It's a workflow problem.

When Ideogram V3's Whitepaper Met Reality

I was building a pipeline to generate interior design variations for an e-commerce platform. The whitepaper showed beautiful examples of architectural spaces with perfect lighting.

Here's the prompt I used from their examples:

"Modern minimalist living room, floor-to-ceiling windows, 
natural light, Scandinavian furniture, architectural photography"
Enter fullscreen mode Exit fullscreen mode

First three generations: perfect. Fourth one: furniture floating off the ground. Fifth: window placement changed. By the tenth iteration, I had seven different room layouts.

Same seed, same parameters, same model version. The issue wasn't randomness—it was me treating each generation as independent. The whitepaper examples worked because they were single, carefully-constructed prompts. I was running iterative experiments without maintaining state.

The fix:

class PromptContext:
    def __init__(self, base_intent):
        self.base_intent = base_intent
        self.style_locks = {}

    def generate_with_memory(self, variation):
        locked = " ".join([f"{k}: {v}" for k, v in self.style_locks.items()])
        return f"{self.base_intent}. {locked}. {variation}"

context = PromptContext("Modern minimalist living room")
context.style_locks["windows"] = "floor-to-ceiling on north wall"
context.style_locks["floor"] = "light oak hardwood"
Enter fullscreen mode Exit fullscreen mode

Cost: 40% more tokens per request. Benefit: went from 60% usable outputs to 95%. The whitepaper shows capability, not workflow. When you can test the same prompt across multiple AI models, the dissonance between documentation and reality becomes measurable rather than frustrating.

SD3.5 Medium's Averaging Problem

I needed product packaging concepts that felt "premium but approachable" for a beverage brand. The brief: Japanese minimalism meets 1970s American optimism.

First attempt:

{
    "prompt": "Premium beverage packaging, minimalist, 
               warm nostalgic colors, sophisticated",
    "cfg_scale": 7.5,
    "sampler": "DPM++ 2M Karras"
}
Enter fullscreen mode Exit fullscreen mode

Result: generic wellness brand aesthetics. Technically perfect. Strategically useless.

I ran 50 variations testing cfg_scale from 5.0 to 12.0:

cfg_scale=5.0  → Lost brand identity
cfg_scale=7.5  → Safe, averaged aesthetics  
cfg_scale=10.0 → Interesting tensions emerged
cfg_scale=12.0 → Overcooked, but committed
Enter fullscreen mode Exit fullscreen mode

The fix: Stop describing the middle ground. Describe the extremes.

prompt_a = "1970s American optimism, warm oranges, 
            rounded typography, sunburst graphics"
prompt_b = "Japanese minimalism, white space, 
            geometric precision"

# Generate separately at cfg_scale=11.0
# Then synthesize specific elements
Enter fullscreen mode Exit fullscreen mode

SD3.5 Medium optimizes for "nothing broken" with vague targets. Give it contradictory specifics and higher CFG, and you get interesting failures to work with. Three unusable images and one brilliant image beats ten mediocre ones.

Trade-off: 3x generation time. But revision time savings made it worth it.

When Nano Banana PRO New Silently Changed

Three-month-old content pipeline. Generated weekly newsletter summaries. Worked fine.

One Monday: every output was 40% shorter and weirdly formal.

Before (v1.2): 480 tokens, conversational. After (v1.3): 310 tokens, corporate.

Release notes: "improved efficiency and coherence." No mention of temperature rescaling.

The diff script I now run:

def model_regression_test(old_model, new_model, test_prompts):
    results = []
    for prompt in test_prompts:
        old_response = generate(old_model, prompt, temp=0.7)
        new_response = generate(new_model, prompt, temp=0.7)

        diff = {
            "length_delta": len(new_response) - len(old_response),
            "formality_delta": analyze_formality(new_response) - 
                              analyze_formality(old_response)
        }

        if abs(diff["length_delta"]) > 100:
            print(f"WARNING: Length shift")
        results.append(diff)
    return results
Enter fullscreen mode Exit fullscreen mode

The actual issue: they changed temperature scaling. temp=0.7 in v1.3 behaved like temp=0.4 in v1.2.

My fix: pin model versions in production, regression test before upgrading.

# requirements.txt
nano-banana-pro==1.2.8  # Regression test before upgrade
Enter fullscreen mode Exit fullscreen mode

"Improved" means "different." Treat model updates like database migrations. Running parallel tests across Nano Banana PRO New and legacy versions reveals what release notes hide.

The Context Switching Tax

My workflow last month:

  1. Draft prompt in ChatGPT
  2. Test in Jupyter notebook
  3. Check results in Notion
  4. Discuss in Slack
  5. Update Google Doc
  6. Re-run notebook
  7. Forget step 1 decisions

I was generating legal disclaimer variations. Each category needed specific regulatory language. I'd test in ChatGPT, worked great. Copy to notebook, different results. Thirty minutes debugging before realizing different model versions.

The system I built:

class ExperimentLog:
    def __init__(self):
        self.conn = sqlite3.connect("experiments.db")
        self.setup_db()

    def log(self, model, prompt, params, output, success, notes=""):
        self.conn.execute("""
            INSERT INTO experiments 
            (timestamp, model, prompt, parameters, output, success)
            VALUES (?, ?, ?, ?, ?, ?)
        """, (datetime.now().isoformat(), model, prompt, 
              json.dumps(params), output[:500], success))

    def get_successful_prompts(self, model):
        return self.conn.execute("""
            SELECT prompt, parameters FROM experiments 
            WHERE model = ? AND success = 1
            ORDER BY timestamp DESC
        """, (model,)).fetchall()
Enter fullscreen mode Exit fullscreen mode

Now I search "legal disclaimers last week" and get exact parameters, model version, output. No re-discovering.

Context switching isn't just a productivity tax—it fragments intent into micro-decisions scattered across tools.

The Long Document Problem

140-page RFP. Needed specific technical requirements. Cross-references, tables, nested appendices.

Tried: upload to ChatGPT, ask questions.

Me: "What are data retention requirements in Section 7?"
ChatGPT: "The document mentions retention in multiple sections..."
Me: "No, I need specific retention periods."
ChatGPT: "Based on the document, periods vary by type..."
Enter fullscreen mode Exit fullscreen mode

Summaries of summaries. Never the actual spec.

The workflow:

def chunk_document(pdf_path, chunk_size=4000):
    reader = pypdf.PdfReader(pdf_path)
    chunks = []

    for i, page in enumerate(reader.pages):
        text = page.extract_text()
        words = text.split()

        for start in range(0, len(words), chunk_size - 200):
            chunks.append({
                "page": i + 1,
                "text": " ".join(words[start:start + chunk_size])
            })
    return chunks

def extract_requirements(pdf_path):
    chunks = chunk_document(pdf_path)
    requirements = []

    for chunk in chunks:
        prompt = f"""Extract technical requirements from:
        Page {chunk['page']}: {chunk['text']}

        Return JSON: {{"requirements": [{{"type": "retention", 
        "spec": "7 years", "section": "7.3.2"}}]}}"""

        result = call_llm_api(prompt)
        requirements.extend(result.get("requirements", []))

    return requirements
Enter fullscreen mode Exit fullscreen mode

Output:

[
  {"type": "retention", "spec": "7 years for financial records", 
   "section": "7.3.2", "page": 45},
  {"type": "retention", "spec": "3 years for operational logs", 
   "section": "7.3.2", "page": 45}
]
Enter fullscreen mode Exit fullscreen mode

Trade-off: more processing time and API costs. But went from 3 hours frustrated questioning to 20 minutes automated extraction. Research papers that took hours to read now take minutes with a Document Summarizer.

What I'd Do Differently

Starting over, I'd version everything. Git for prompts, not just code. Build logging first—wasted weeks re-discovering experiments. Test edge cases, not happy paths. The whitepaper examples are optimized demos. Automate diffs and treat model updates like schema migrations.

This is still evolving. If you've hit similar workflow issues, drop a comment.

-Leena:)

Top comments (0)