KI-gestützte Softwareentwicklung

Aktive Diskrepanz-Bewältigung

Das NBRX-Entwicklerteam arbeitet in verschiedenen Projekten, die unterschiedlich stark auf KI setzen und teils schärferen Auflagen unterliegen. Das hat langfristig zu einer Diskrepanz in unseren KI-Kenntnissen geführt. Da KI-Unterstützung im Entwicklungsprozess nicht mehr wegzudenken ist, erkläre ich im folgenden Begrifflichkeiten und möchte damit den Wissensaustausch fördern.

Dass ich gerade jetzt über Copilot-Kosten, Tokens und Kontext spreche, hat einen Grund: Wir setzen – soweit nicht durch Kunden anders vorgegeben – auf GitHub Copilot. Da Microsoft Anfang Juni das Preismodell angepasst hat, nehme ich dies als Aufhänger, um zu vermitteln, wie KIs arbeiten und wie die Kosten zustande kommen.

Von der Euphorie zur bewussten Nutzung

Wir bewegen uns langsam von der anfänglichen Euphorie weg – in der wir uns daran gemessen haben, wie viele Agents man 24/7 beschäftigt hat – hin zu einer Richtung, in der KI gezielter eingesetzt werden soll. Beispiele wie Uber zeigen, dass KI bewusst eingesetzt werden muss und Kosten nicht vernachlässigbar sind, sondern gegen das Erbrachte aufgewogen werden müssen.

Was ist zu verstehen? Die Stolpersteine im Alltag

1. Das Kontext-Problem

Ein Punkt, auf den ich viel Wert lege, der aber oft vernachlässigt wird: die Kapazität des Kontexts. Viele Entwickler ignorieren, dass die KI ihre Sitzung zusammenfassen muss, wenn die Kontextkapazität erschöpft ist. So wie Zusammenfassungen Details auslassen, muss auch die KI entscheiden, was relevant ist. Das führt oft zu schlechterer Performance und Frust. Selbst ohne Zusammenfassungen sinkt die Qualität der Antworten, je „voller“ der Kontext wird, wie dieses Paper von Februar 2026 zeigt. Mehr Kontext ist also nicht immer automatisch besser, ein fast voller Kontext ist nur „weniger schlecht“ als das Zusammenfassen.

2. Begriffs-Wirrwarr: Agents, MCPs, Skills und Instructions

• Agents: Ich betrachte sie eher als Persona (wie im Marketing), anstatt nur als autonome Loops. Sie erlauben für bestimmte Arbeitsschritte granulare Regeln, Vorgehensweisen und erlaubte Programme festzulegen. Und wenn man möchte kann man sie auch autonom arbeiten lassen, muss es aber nicht.
• MCPs (Model Context Protocol): Für mich wie eine API, aber mit dem Unterschied, dass fachlich definierte Tools gebündelt werden und Daten direkt transformiert werden können (z. B. für Jira- oder Git-Tasks).
• Skills: Beschreiben das Wie. Frontend-Entwickler definieren hier Abstände oder Schriftarten, Backend-Entwickler Prüflogiken für API-Routen.
• Instructions: Das, was Microsoft für Copilot nutzt (Anthropic/OpenAI nennen es Rules). Sie sind immer geladen und sollten möglichst allgemeingültig sein (z. B. Code-Style).

Best Practices: Mein Workflow

Ich persönlich lasse KI meine Konzepte challengen. Eine "neutrale" dritte Meinung deckt Inkonsistenzen auf, die man durch die selben Gedankengänge im Pair Programming gerne übersieht. Zudem nutze ich die KI als zweiten Code-Reviewer: Sie prüft zuverlässig technische Anforderungen wie Input-Validierungen oder fehlende Unit-Tests, während ich mich auf Architektur und fachliche Abnahme fokussiere.

• Self-Learning: Am Ende jeder Aufgabe muss die KI aus meinen Korrekturen und ihren selbst aufgedeckten Fehlern lernen und diese in eine zentrale Datei schreiben, die vor jedem neuen Start gelesen wird.
• Plan-First: Ich implementiere nie ohne einen vorherigen Plan. Ich lasse mir die Vorgehensweise, die relevantesten Dateien und Risiken anzeigen, um Korrekturen vorzunehmen, bevor eine Zeile Code geschrieben wurde.

Warum die KI teurer wird

Die Anbieter stellen massiv auf nutzungsbasierte Abrechnung um. Grund dafür ist, dass die benötigte Rechenleistung nicht linear mit dem Kontext, sondern quadratisch, steigt. Da wir KI nun konstant zur Prozessoptimierung einsetzen und nicht mehr nur als „Google-Ersatz“, sind Pauschalpreise für Anbieter nicht mehr haltbar.

Aus diesem Grund sollten wir KI bewusst und gezielt einsetzen und eine auf die Anforderungen abgestimmte Modellauswahl treffen. Für Planungsschritte mit hohem Reasoning-Bedarf sollten also die starken Modelle genutzt werden. Wohingegen für Dokumentations-Updates oder einfache Skripte schwächere Modelle vollkommen ausreichen. Wer immer das teuerste Modell wählt, verschwendet Tokens und Budget.