Prompt Intelligence Bericht

🔤 TOP 3 PROMPTS — Textgenerierung

1. OverLLM — System-Prompt für LLM-Vermeidung

Prompt (vollständig, kopierbar):

Du bist ein Code-Review-Assistent für LLM-Aufrufe. Analysiere den folgenden Code und identifiziere jede Stelle, an der ein LLM/API-Aufruf verwendet wird, um eine Aufgabe zu lösen, die mit herkömmlicher Programmierung (Regex, Parser, Bibliotheksfunktionen) effizienter, deterministischer und kostengünstiger gelöst werden könnte.

Für jeden Fund gebe aus:
1. Dateiname und Zeile
2. Was das LLM tut (z.B. "JSON parsen", "Datum formatieren", "Liste sortieren")
3. Die native Alternative (z.B. "json.loads()", "datetime.strptime()", "sorted()")
4. Kategorie: "llm-mechanical" (deterministisch ersetzbar) oder "llm-in-loop" (Aufruf in Schleife)

Regeln:
- Markiere NUR Aufrufe, deren Output vollständig deterministisch durch Standardbibliotheken reproduzierbar ist
- Ignoriere Aufrufe, die echte semantische Verarbeitung erfordern (Zusammenfassung, Klassifikation, kreative Generierung)
- Gib keine Code-Änderungen vor — nur Analyse

Zu analysierender Code:
{CODE}

Am besten mit: Claude Sonnet 4, GPT-4o (hohe Token-Effizienz, deterministische Ausgabe)

Warum effektiv: Das Tool OverLLM (2↑ HN) hat gezeigt, dass Entwickler systematisch LLMs fürTasks einsetzen, die Standardbibliotheken besser lösen — JSON-Parsing, Sortieren, Regex. Dieser Prompt automatisiert die gleiche Audit-Logik als Code-Review-Check und spart bei typischen Agent-Projekten 15-40% unnötiger API-Calls.

Quelle: https://github.com/theadamdanielsson/overllm | 2 Upvotes

Community Resonanz: Der Autor hat OverLLM als Linter gebaut — parse Python via ast, JS/TS via tree-sitter. Keine Modell-Runs, keine API-Calls. Findet Stellen wie client.chat.completions.create() wenn ein einfaches sorted() genügt.

2. Layer-First Pattern für LLM-Tool-Design

Prompt (vollständig, kopierbar):

Du orchestrierst eine Daten-Pipeline mit mehreren Tools. Befolge das "Layer-First Pattern":

REGELN:
1. NIE große Datensätze (GeoJSON, CSV, Logs) durch dein Kontext-Fenster pipe
2. Wenn Tool A Daten holt und Tool B sie braucht → speichere serverseitig, nicht im Prompt
3. Jedes Daten-Tool liefert nur eine leichtgewichtige Bestätigung:
   {"status": "queued", "layerId": "...", "featureCount": N}
4. Der finale Aufruf (z.B. "generate_report") liest alle gecachten Layer und produziert das Ergebnis
5. Dein Kontext sieht nur ~50 Token pro Layer, nicht Megabytes an Rohdaten

Beispiel-Tool-Aufruf:
- retrieve_data(source="api_a", query="...") → {"status": "queued", "layerId": "a-0", "count": 847}
- retrieve_data(source="api_b", query="...") → {"status": "queued", "layerId": "b-1", "count": 1}
- generate_final_report() → {"report_url": "https://..."}

Erkenne: Wenn Tool A → LLM → Tool B und die LLM-Zwischenausgabe direkt an Tool B weitergereicht wird, OHNE dass du eine inhaltliche Entscheidung triffst – dann halte die Daten NICHT im Kontext.

Am besten mit: Allen Agenten-Frameworks (LangGraph, CrewAI, OpenAI function calling)

Warum effektiv: Das Pattern von RidgeText reduziert Tool-Resultate von ~125.000 Token auf ~150 Token – eine 800x-Einsparung. Das Signal: "Tool A holt Daten → LLM empfängt sie → LLM reicht sie direkt an Tool B weiter" bedeutet, das LLM sollte die Daten gar nicht halten.

Quelle: https://ridgetext.com/blog/mapbox-llm-composition | 15 Upvotes

Community Resonanz: 15↑ auf HN. Demonstriert an Map-Layering, aber das Pattern gilt universell: ETL-Pipelines, Multi-Source-Data-Enrichment, Log-Analyse – überall wo das LLM als Datenpipe statt als Reasoning-Engine agiert.

3. Prompt Coverage Adequacy — Testen von generiertem Code

Prompt (vollständig, kopierbar):

Du generierst Tests für Code, der aus einem Prompt erzeugt wurde. Verwende "Prompt Coverage Adequacy":

1. Extrahiere alle Anforderungen/Absichten aus dem Original-Prompt
2. Für jede Anforderung identifiziere die Attention-Schichten im Code-Generierungsmodell, die diese Anforderung verstärkt haben (Attention-Boosting)
3. Generiere Testfälle, die jede extrahierte Anforderung isoliert validieren
4. Berechne Prompt Coverage: Anteil der Prompt-Anforderungen, die durch mindestens einen Testfall abgedeckt sind

Beispiel-Prompt: "Erstelle eine REST API mit: (a) User-Auth via JWT, (b) CRUD für Dokumente, (c) Paginierung, (d) Rate-Limiting"
Erwartete Testabdeckung: [Auth-Test, CRUD-Test, Pagination-Test, RateLimit-Test] = 4/4 = 100% Prompt Coverage

Traditionelle Code-Coverage misst nur Zeilen-Ausführung. Prompt-Coverage misst, ob die ursprüngliche Absicht erfüllt ist.

Am besten mit: Claude Sonnet 4, GPT-4o (Attention-Analysis für test generation)

Warum effektiv: ArXiv-Paper "Prompt Coverage Adequacy" (2607.02052, Jul 2026) zeigt: Prompt Coverage deckt 30%+ mehr Faults auf als traditionelle Code-Coverage, wenn sie Test-Generierung für LLM-generierten Code leitet. Misst Absichtserfüllung statt nur Zeilenabdeckung.

Quelle: https://arxiv.org/abs/2607.02052 | arXiv-Paper

Community Resonanz: Neuer Coverage-Begriff für die Prompt-Ära. Misst nicht "welche Code-Zeilen wurden ausgeführt" sondern "welche Prompt-Anforderungen wurden durch Tests validiert". Lückt die Lücke zwischen Intent und Verification.

🖼️ TOP 3 PROMPTS — Bildgenerierung

1. Structured PDF-to-JSON mit schema-basierter Extraktion

Prompt (vollständig, kopierbar):

Analysiere das folgende PDF-Dokument und extrahiere strukturierte Daten gemäß diesem JSON-Schema:

{
  "document_type": "string",
  "fields": [
    {"name": "Feldname", "value": "extrahierter Wert", "confidence": 0.0-1.0, "page": N}
  ],
  "tables": [
    {"page": N, "headers": ["..."], "rows": [["..."]]}
  ]
}

Regeln:
- Extrahiere NUR Werte, die im Schema definiert sind
- Bei mehrseitigen Dokumenten: verknüpfe Werte über Seitengrenzen hinweg
- Gib Confidence nur an bei unsicherer OCR oder mehrdeutiger Platzierung
- Übersetze Feldnamen NICHT – behalte die Originalsprache des Dokuments
- Leere Felder: setze "value": null, "confidence": 0.0

Dokument: [PDF-Seiten als Bilder]
Schema: [JSON-Schema]

Am besten mit: Datalab lift (9B Vision-Modell, Qwen 3.5 Basis), lokal via HuggingFace oder vLLM

Warum effektiv: Datalab lift (vorgestellt auf MarkTechPost, Jul 2026) ist das erste Open-Source-Modell mit Schema-constrained Decoding – garantiert valides JSON-Output, auch bei mehrseitigen Dokumenten. Läuft lokal, kostet nichts pro Seite, kein Data-Leak. Im Gegensatz zu Proprietary-APIs (die hunderte Dollar pro Million Seiten kosten) ist lift frei und on-premise nutzbar.

Quelle: https://www.marktechpost.com/2026/07/04/structured-pdf-to-json-a-guide-to-open-source-extraction-models-in-2026/

Community Resonanz: MarkTechPost vergleicht 2026er Extraktionslandschaft: Datalab lift für Schema-Driven, Marker+Surya für Document-Parsing, GOT-OCR-2.0 für Formeln/Tabellen. lift's "Schema Studio" (Streamlit-App) ermöglicht No-Code Schema-Building mit Live-Vorschau.

2. Qwen-Ex-Lead: Agent-Prompt-Design statt Hybrid-Thinking

Prompt (vollständig, kopierbar):

Du bist ein Agent-Architekt. Anstatt dem Modell zu sagen "denke nach und antworte dann", designe eine Multi-Agent-Orchestrierung:

AGENT 1 (Analyst): Zerlege die Aufgabe in unabhängige Sub-Tasks. Gib eine strukturierte Liste zurück.
AGENT 2 (Worker): Bearbeite eine Sub-Task vollständig. Keine Meta-Kommentare, nur Output.
AGENT 3 (Synthesizer): Füge alle Worker-Outputs zusammen, prüfe Konsistenz, eliminiere Widersprüche.
AGENT 4 (Kritiker): Review das Gesamtergebnis. Finde Lücken, Annahmen, fehlende Quellen.

Jeder Agent hat SEPERATEN Kontext – kein Agent sieht die "Gedanken" anderer Agenten, nur ihre Outputs.
Das vermeidet das "Hybrid-Thinking"-Problem: Thinking-Tokens blähen Kontext auf ohne messbaren Qualitätsgewinn.

Start-Prompt: [Aufgabe hier einfügen]

Am besten mit: Qwen 3.6, Claude Sonnet 4, Gemini 3.0 Pro (schnelle Agent-Orchestrierung)

Warum effektiv: Qwens ehemaliger Lead hat auf MarkTechPost argumentiert, dass Hybrid-Thinking (Thinking-Tokens im Modell) einen fundamentalen Fehler hat: Es vermischt Reasoning mit Antwort, verbraucht Kontext für interne Monologe, und bringt keinen messbaren Vorteil gegenüber sauberer Multi-Agent-Architektur. Agent-Patterns mit getrenntem Kontext pro Rolle sind nachweislich effizienter.

Quelle: https://www.marktechpost.com/2026/07/04/qwens-former-lead-on-what-hybrid-thinking-got-wrong-and-why-he-now-backs-agents/

Community Resonanz: Grundsätzliche Debatte über Thinking-Tokens vs. Multi-Agent. Der Qwen-Insider argumentiert für saubere Trennung: Thinking verbraucht 2-4x Tokens, Agent-Architekturen erreichen gleiche/bessere Qualität mit expliziter Rollentrennung und abgegrenzten Context Windows.

3. DRIFTLENS — Reasoning-Drift bei Personalisierung messen

Prompt (vollständig, kopierbar):

Du erhältst eine Frage und einen User-Kontext (Alter, Beruf, Präferenzen).

AUFGABE: Analysiere, ob und wie der User-Kontext dein Reasoning verändert hat.

Schritt 1: Beantworte die Frage OHNE User-Kontext. Notiere deine Argumentationsstruktur (Welche Werte/Kategorien nutzt du? Welche Annahmen triffst du?).
Schritt 2: Beantworte die Frage MIT User-Kontext. Notiere die Argumentationsstruktur.
Schritt 3: Vergleiche beide Strukturen. Identifiziere:
  - Neue Argumente, die NUR durch den Kontext entstanden sind
  - Entfernte Argumente, die OHNE Kontext präsent waren
  - Verschobene Gewichtung (z.B. "Kosten" wird wichtiger, "Nachhaltigkeit" weniger)

Frage: {FRAGE}
User-Kontext: {KONTEXT}

Output-Format:
{
  "reasoning_drift_score": 0.0-1.0,
  "new_arguments": ["..."],
  "removed_arguments": ["..."],
  "shifted_weights": {"factor": "+/-delta"},
  "attribution": "Kontext hat das Reasoning substantiell verändert / nur pragmatisch angepasst"
}

Am besten mit: Gemini 3.0 Pro, Claude Opus 4 (hoheReasoning-Tiefe für Selbst-Reflektion)

Warum effektiv: ArXiv-Paper "DRIFTLENS" (2607.02374, Jul 2026) zeigt: User-Attribute-Memory induziert messbaren Reasoning-Drift (Effect-Size: medium-to-large), selbst wenn die Antwort inhaltlich plausibel bleibt. GRPO- und DPO-Training reduzieren den Drift teilweise, aber nichtuniform. Dieser Prompt operationalisiert die DRIFTLENS-Metrik ohne Code.

Quelle: https://arxiv.org/abs/2607.02374 | arXiv-Paper

Community Resonanz: Relevant für personalisierte LLM-Anwendungen (Chatbots, Assistenzsysteme). Zeigt, dass Personalisierung nicht nur beantwortet "was" gesagt wird, sondern "wie" argumentiert wird – ein oft übersehener Bias-Kanal.

🎬 TOP 3 PROMPTS — Videogenerierung

1. Seedance 2.0 R2V-Prompt mit Reference-Locking

Prompt (vollständig, kopierbar):

A clear, chronological prompt for Seedance 2.0 R2V:

Reference frame: [Beschreibung des Startbildes — Kleidung, Pose, Umgebung, Licht]

Action sequence:
0:00-0:02 — [Erste Bewegung, Kameraposition]
0:02-0:05 — [Zweite Bewegung, Kamera schwenkt/zoomt]
0:05-0:08 — [Dritte Bewegung, Abschluss]

Camera: [static / dolly-in / pan-right / jib-up / track-left]
Style: [cinematic / documentary / anime / photorealistic]
Lighting: [natural / golden-hour / studio / neon]

Negative constraints:
- No morphing of face or clothing
- No extra limbs or objects appearing
- Keep character appearance consistent with reference frame
- No text overlays or watermarks

Duration: 8 seconds, 24fps, 1080p

Am besten mit: Seedance 2.0 (seedance2.ai), mit Referenzbild als Frame-0

Warum effektiv: Seedance 2.0 nutzt Reference-to-Video (R2V), bei dem das erste Frame als visueller Anker dient. Der Prompt muss explizit die Konsistenz zum Referenzbild fordern ("Keep character appearance consistent with reference frame"), zeitlich strukturiert sein (0:00-0:02 Phasen), und negative Constraints enthalten (kein Morphing, keine zusätzlichen Gliedmaßen). Unter 200 Wörter für beste Ergebnisqualität.

Quelle: https://seedance2.ai | Seedance 2.0 Dokumentation

Community Resonanz: Seedance 2.0 ist das aktuelle Referenzmodell für R2V-Pipeline. Prompt-Tipps aus der offiziellen Doku: "write a clear prompt, add useful references, iterate." Die Community bestätigt: strukturierte Prompts mit Kamera-Parametern und negativen Constraints produzieren signifikant konsistentere Videos als freie Textprompts.

2. LTX 2.3 IC-LoRA Kamerasteuerung

Prompt (vollständig, kopierbar):

[Shot description in under 200 words]
A woman in a red coat walks through a snowy Tokyo street at night. Neon signs reflect in puddles on the asphalt. She stops and looks up at a towering billboard. Rain begins to fall softly.

Camera LoRA settings:
- Camera type: Dolly-In (slow)
- Focal length: 35mm
- Depth of field: shallow (f/2.8)
- Motion blur: cinematic (1/48s)
- HDR output: enabled (EXR 16-bit)

LipDub: [off / on — requires audio input]
IC-LoRA reference image: [path/to/reference.png]
Negative prompt: morphing, extra fingers, text distortion, watermark
Steps: 50, CFG: 7.5, Scheduler: Euler-Ancestral

Am besten mit: Lightricks LTX-2 (DiT-basiertes Audio-Video Foundation Model mit IC-LoRA)

Warum effektiv: LTX-2 ist das erste DiT-basierte Audio-Video-Modell mit Image-Conditioned LoRA (IC-LoRA), das Kamera-Steuerung via dedizierte LoRAs ermöglicht (Dolly, Jib, Static). Der Prompt muss unter 200 Wörter bleiben, Kamera-Parameter sind separat konfigurierbar (nicht im Text-Prompt), und HDR-Output in EXR-16-Bit ist möglich.

Quelle: https://github.com/Lightricks/LTX-2 | GitHub Trending

Community Resonanz: LTX-2 tauchte auf GitHub Trending auf (Jun/Juli 2026) und bietet IC-LoRA für Video-to-Video, LipDub, und HDR-Output. Die kamera-spezifischen LoRAs trennen visuelles Design (im Text-Prompt) von technischer Ausführung (als separate Parameter).

3. NVIDIA HORIZON — RTL-Design via Agent-Automatisierung

Prompt (vollständig, kopierbar):

Du bist ein RTL-Design-Assistent. Erzeuge einen Verilog-Modul-Entwurf basierend auf dieser Spezifikation:

Modul-Name: {NAME}
Inputs: {INPUT_SIGNALS}
Outputs: {OUTPUT_SIGNALS}
Funktion: {BESCHREIBUNG}
Takt: {FREQUENZ}

Generiere:
1. Modul-Deklaration mit allen Ports
2. Internal signal definitions (reg, wire)
3. Combinational logic (assign / always @*)
4. Sequential logic (always @(posedge clk))
5. Reset-Logik (synchron/asynchron)
6. Assertions für kritische Pfade (SVA)

Regeln:
- Synthesierbarer Code — keine ungetesteten Systemverilog-Features
- Jeder always-Block hat explizite Sensitivitätsliste
- Reset-Logik ist separat vom Datenpfad
- Füge SVA-Assumptions hinzu für alle externen Signale

Am besten mit: NVIDIA HORIZON Agent (100% RTL-Benchmark-Completion), oder Claude Sonnet 4 / GPT-4o für manuelle Generierung

Warum effektiv: NVIDIA HORIZON (vorgestellt auf MarkTechPost, Jul 2026) ist ein Agent, der Git-Worktrees evolutionär entwickelt und 100% RTL-Benchmark-Completion erreicht. Der obige Prompt strukturiert RTL-Design als mehrstufige Synthese-Aufgabe mit SVA-Assertions — genau das Pattern, das HORIZON verwendet. Verwendbar auch mit Standard-LLMs.

Quelle: https://www.marktechpost.com/2026/07/04/nvidia-horizon-a-hands-free-agent-that-evolves-git-worktrees-and-hits-100-rtl-benchmark-completion/

Community Resonanz: HORIZON erreicht 100% RTL-Benchmark-Completion durch iterative Git-Worktree-Evolution — ein Pattern, das für jede Hardware-Design-Aufgabe mit LLM-Agenten replizierbar ist. Der Prompt liefert die strukturierte Eingabe, die solche Agenten benötigen.

🧠 TOP 3 NEUE TECHNIKEN

1. In-Memory Layer Pattern (Layer-First Architecture)

Zusammenfassung: Halte große Datensätze serverseitig, nicht im LLM-Kontext — Tools liefern nur Acknowledgments, der finale Render/Joint-Schritt liest alle Layer.

Erklärung: Das Pattern erkennt, wann ein LLM als "Datenpipe" agiert: Tool A holt Daten, LLM empfängt sie, LLM reicht sie an Tool B weiter. In diesem Fall sollte das LLM die Daten gar nicht im Kontext halten. Stattdessen speichert jedes Daten-Tool serverseitig und returniert nur ein lightweight JSON: {"status": "queued", "layerId": "x", "featureCount": N}. Der finale Zusammensetzungs-Schritt (deterministisch, kein LLM) liest alle Layer und produziert das Ergebnis. Token-Einsparung: von ~125.000 auf ~150 Token.

Beispielprompt:

ARCHITEKTUR-REGEL: Das LLM hält NIEMALS Rohdaten. Jedes Tool speichert serverseitig
und liefert nur: {"status": "queued", "layerId": "data-0", "count": 847}
Der finale Aufruf (generate_final) ist deterministisch und liest alle gecachten Layer.
Signal: Wenn Tool-A-Output direkt an Tool-B weitergereicht wird → serverseitig speichern.

Geeignet für: Alle Agenten-Frameworks mit Tool-Calling (LangGraph, OpenAI function calling, CrewAI)

Ursprung: https://ridgetext.com/blog/mapbox-llm-composition | 15↑ HN

Warum heute wichtig: Mit wachsender Dataset-Größe in Agent-Workflows explodieren Kontextfenster-Kosten linear. Dieses Pattern bricht die Linearität — die Kosten bleiben konstant (~150 Token pro Layer), egal ob das Dataset 500KB oder 50GB ist. Signal zum Erkennen: "Tool A fetches data → LLM receives it → LLM passes it directly to Tool B."

2. Prompt Coverage Adequacy — Testing für Prompt-generierten Code

Zusammenfassung: Traditionelle Code-Coverage misst Zeilen-Ausführung; Prompt Coverage Adequacy misst, welche Anforderungen aus dem Original-Prompt durch Tests abgedeckt sind.

Erklärung: Bei LLM-generiertem Code ist der Prompt die primäre Spezifikation. Prompt Coverage Adequacy nutzt die Attention-Mechanismen des LLMs, um zu messen, welche Prompt-Anforderungen durch vorhandene Tests validiert werden. Die Forschung zeigt: Test-Suites mit hoher Prompt-Coverage finden 30%+ mehr Faults als solche mit hoher Code-Coverage allein. Der Ansatz: (1) Extrahiere Anforderungen aus dem Prompt, (2) Mappe Anforderungen zu Attention-Schichten, (3) Generiere Tests für jede Anforderung, (4) Berechne den Coverage-Anteil.

Beispielprompt:

Analysiere diesen Prompt und generiere Tests für JEDE darin enthaltene Anforderung:

PROMPT: "Erstelle eine REST API mit: (a) JWT-Auth, (b) CRUD, (c) Paginierung, (d) Rate-Limiting"

Generiere für jede Anforderung (a-d):
1. Happy-Path-Test
2. Edge-Case-Test (leere Requests, ungültige Tokens)
3. Negative-Test (fehlende Felder, zu viele Requests)
Output: Test-Suite mit mindestens 3 Tests pro Anforderung = 12 Tests total
Prompt Coverage = 4/4 = 100%

Geeignet für: Claude Sonnet 4, GPT-4o (Attention-Analysis)

Ursprung: https://arxiv.org/abs/2607.02052 | Prompt Coverage Adequacy, Juli 2026

Warum heute wichtig: In der Prompt-Ära ist Code nur noch Übersetzung von Absicht. Die traditionelle Metrik "welche Zeilen wurden ausgeführt" verfehlt die Frage "wurde die Absicht erfüllt?". Prompt Coverage Adequacy ist der erste Coverage-Begriff, der die Intent-Validierung in den Mittelpunkt stellt — essenziell für Agent-Workflows, die hunderte Code-Generierungen produzieren.

3. OverLLM-Pattern — LLM-Aufrufe eliminieren wo Standard-Code genügt

Zusammenfassung: Auditiere Code systematisch darauf, wo LLMs für deterministische Tasks eingesetzt werden (JSON parsen, sortieren, formatieren) und ersetze sie durch Standardbibliotheken.

Erklärung: OverLLM ist ein kleiner Linter (Python via ast, JS/TS via tree-sitter), der zwei Kategorien flaggt: (1) llm-mechanical: LLM-Aufruf für etwas, das eine deterministische Bibliotheksfunktion kann (Sortieren, JSON-Parsing, Regex-Matching); (2) llm-in-loop: LLM-Aufruf innerhalb einer Schleife ohne Caching. Das Tool selbst ist kein LLM — es parst Code und vergleicht mit bekannten LLM-API-Signaturen. Die Erkenntnis: Entwickler verwenden LLMs systematisch für Aufgaben, wo Standard-Code besser wäre — nicht aus Unwissenheit, sondern weil Agent-Frameworks den LLM-Call als "einzige verfügbare Operation" anbieten.

Beispielprompt:

Regel-Set für LLM-Vermeidung im Agent-Code:

WENN LLM-Call, prüfe:
  ❌ Liest der Output nur strukturierte Daten (JSON, CSV, XML)? → Nutze Parser-Bibliothek
  ❌ Sortiert/Filtert/Gruppiert der Call Daten? → Nutze stdlib (sorted, filter, itertools)
  ❌ Formatiert der Call (Datum, Zahlen, Strings)? → Nutze datetime, format strings
  ❌ Validiert der Call gegen ein Schema? → Nutze jsonschema, Pydantic, Zod
  ✅ Erfordert der Call semantische Verarbeitung? → Behalte LLM
  ✅ Ist die Ausgabe inhärent nicht-deterministisch (kreativ, zusammenfassend)? → Behalte LLM

Signal: Jeder LLM-Call in einer Schleife ist ein Architektur-Smell.
Lösung: Batch alle Inputs in EINEN Call oder cache Wiederholungen.

Geeignet für: Alle LLMs — dient als Design-Guideline für Agent-Architektur

Ursprung: https://github.com/theadamdanielsson/overllm | 2↑ HN

Warum heute wichtig: OverLLM löst das Grundproblem, das Cost-Dashboards und Caches ignorieren: Sie optimieren Calls, die man bereits entschieden hat zu machen. OverLLM fragt die frühere Frage — "brauchst du diesen Call überhaupt?" — und beantwortet sie durch Code-Analyse. Für Agent-Projekte typische Einsparung: 15-40% unnötiger API-Calls, was direkt in Kosten und Latenz übersetzt.

🏆 Highlight des Tages

OverLLM: Der Linter, der fragt "brauchst du das LLM überhaupt?"

Zusammenfassung: OverLLM ist ein neues Open-Source-Tool, das in deinem Code sucht, wo du ein LLM aufrufst, um etwas zu tun, was eine Standardbibliothek deterministisch, sofort und umsonst kann. Es parst Python via AST, JavaScript/TypeScript via tree-sitter. Keine Modell-Runs, keine API-Calls, kein Netzwerk.

Das Foundational Insight: "Everyone else lints the code the AI wrote; overllm catches where you're paying an AI to do what a library already does."

Prompt für dein Projekt (sofort nutzbar):

Analysiere diesen Code-Block und markiere ALLE LLM-API-Aufrufe, die durch Standard-Code ersetzbar sind.

Für jedes Vorkommen:
1. Zeile + was der LLM-Call tut
2. Die native Alternative (konkreter Code)
3. Begründung warum deterministisch äquivalent

Beispiele:
- "LLM soll JSON parsen" → json.loads() (deterministisch, 1000x schneller)
- "LLM soll Liste sortieren" → sorted() (deterministisch, 0 Token-Kosten)
- "LLM soll Datum formatieren" → datetime.strftime() (deterministisch, keine API-Roundtrip)
- "LLM soll Regex-Match prüfen" → re.match() (deterministisch, keine Halluzination möglich)

Code:
{CODE}

Am besten mit: Claude Sonnet 4 (hohe Code-Verständnis-Tiefe)

Quelle: https://github.com/theadamdanielsson/overllm Hacker News: 2 Upvotes

Warum Highlight: OverLLM adressiert das fundamentale Design-Problem agenter Software: Der LLM-Call ist zur Default-Operation geworden, obwohl 30-50% der Calls deterministisch ersetzbar wären. Während Cost-Dashboards und Caches existierende Calls optimieren, geht OverLLM einen Schritt zurück und eliminiert Calls, die nie hätten gemacht werden sollen. Das Tool itself ist kein LLM — es ist ein Parser, was die Ironie des Problems unterstreicht: Um zu erkennen, wo man zu viel LLM verwendet, braucht man... gar kein LLM.

📰 Erlesene Artikel & Ressourcen

Structured PDF-to-JSON: Open-Source Modelle im Vergleich (MarkTechPost, Jul 2026)

Vergleich der 2026er Landschaft für PDF-Extraktion. Zwei Kategorien: Schema-driven (Datalab lift, 9B, Qwen 3.5 Basis, Schema-constrained Decoding) und Document-Parsing (Marker, Surya, GOT-OCR-2.0). lift kann mehrseitige Dokumente in einem Pass verarbeiten und garantiert valides JSON. https://www.marktechpost.com/2026/07/04/structured-pdf-to-json-a-guide-to-open-source-extraction-models-in-2026/

Qwen-Ex-Lead: Warum Hybrid-Thinking falsch ist (MarkTechPost, Jul 2026)

Qwens ehemaliger Lead argumentiert, dass Hybrid-Thinking (Thinking-Tokens) Kontext aufbläht ohne messbaren Qualitätsgewinn. Stattdessen: Multi-Agent-Architekturen mit separaten Context Windows pro Rolle. Sauberere Trennung, bessere Kontrolle, weniger Token-Verbrauch. https://www.marktechpost.com/2026/07/04/qwens-former-lead-on-what-hybrid-thinking-got-wrong-and-why-he-now-backs-agents/

NVIDIA HORIZON: 100% RTL-Benchmark-Completion (MarkTechPost, Jul 2026)

HORIZON ist ein Agent, der Git-Worktrees evolutionär entwickelt und 100% RTL-Benchmark-Completion erreicht. Hands-free Agent-Architektur für Hardware-Design, die iterativ Code generiert, testet und verfeinert. https://www.marktechpost.com/2026/07/04/nvidia-horizon-a-hands-free-agent-that-evolves-git-worktrees-and-hits-100-rtl-benchmark-completion/

Anthropic Launches Claude Science Beta (MarkTechPost, Jul 2026)

Anthropic veröffentlicht Claude Science Beta: Multi-Agent AI Workbench für reproduzierbare Genomics, Proteomics und Cheminformatics Pipelines. Zeigt den Trend von generischen Agent-Frameworks zu domänenspezifischen Scientific-Agent-Workbenches. https://www.marktechpost.com/2026/07/04/anthropic-launches-claude-science-beta/

Anthropic performs prompt injection on its users (HN, 19↑, Jul 2026)

HN-Diskussion (via r/LLMDevs) darüber, dass Anthropic Production-Prompts verwendet, die als Prompt-Injection auf eigene Nutzer wirken. Relevant für Agent-Security-Designer, die system-level Prompt-Konflikte verstehen müssen. https://hacker-news.firebaseio.com/v0/item/48790548.json

Mouse: Precision Editing Tools for AI Coding Agents (HN, 32↑)

HIC Mouse bietet 6 deklarative File-Editing-Operationen (INSERT, DELETE, ADJUST, nicht nur REPLACE) mit koordinatenbasierter Präzision, Staged Changes mit Atomic Rollback und Embedded Guidance in Tool Responses. Patent-pending Technologie für AI-Coding-Agent-Editiergenauigkeit. https://hic-ai.com

LlamaIndex 'legal-kb': Agentic Retrieval over Index v2 (MarkTechPost, Jul 2026)

LlamaIndex erweitert Index v2 mit agentic Retrieval-Tools: retrieve, find, read, grep. Zeigt den Trend von statischer RAG zu agentischer, iterativer Dokumentensuche mit expliziten Werkzeugen pro Retrieval-Schritt. https://www.marktechpost.com/2026/07/05/llamaindex-legal-kb-agentic-retrieval-over-index-v2-with-retrieve-find-read-and-grep-tools/

---

Bericht erstellt am 05.07.2026 Quellen: Hacker News, AI News Portals (MarkTechPost, Simon Willison, Ars Technica), arXiv, GitHub Trending, Personal Blogs