Mein erster Projektantrag wurde abgelehnt. (Mein alter Antrag findet Ihr im Anhang)

Feedback:
Die Beschreibung des Projektes ist zu knapp. Es wird nicht deutlich inwiefern das Projekt die notwendige Komplexität für ein Projekt in der Anwendungsentwicklung hat. Die Beschreibung muss dahingehend konkretisiert werden, was soll im Detail erreicht werden und was ist die Implementierungsidee? Welche Probleme werden den gelöst? Wie tief sollen die Commits analysiert werden? Inhaltlich? Sollen die Inhalte mit dem Code verglichen werden?

Es fehlt weiterhin die nachvollziehbare Begründung, weshalb für dieses Vorhaben überhaupt KI erforderlich ist. Da zugleich von benutzerdefinierten Regeln gesprochen wird, wirken die genannten Beispiele derzeit auch ohne KI umsetzbar, sodass der KI-Einsatz eher wie Overengineering erscheint.

Falls der Einsatz von KI bereits fest vorgesehen ist, muss klar beschrieben werden, welche Art von KI genutzt werden soll, etwa ein fertiges LLM, und wie diese technisch eingebunden wird. Bitte Buzzwords vermeiden und stattdessen den konkreten Mehrwert fachlich sauber darstellen.

Mein Neuerantrag:

Beschreibung:
Dieses Projekt zielt auf die Entwicklung eines Werkzeugs zur automatischen Validierung von Commit-Nachrichten in Git-basierten Entwicklungsumgebungen ab. Im Unterschied zu einfachen Lösungen mit statischen Regeln kombiniert das System eine deterministische Prüfung mit einer semantischen Analyse auf Basis künstlicher Intelligenz. Ziel ist es, nicht nur formale Regeln einzuhalten, sondern auch sprachliche Qualität und Verständlichkeit der Commit-Nachrichten sicherzustellen.

Das System wird über einen Git-Hook (z. B. commit-msg) direkt in den Workflow integriert und prüft die Commit-Nachricht vor dem endgültigen Commit. Es wird ausschließlich der Text der Nachricht analysiert; der geänderte Quellcode wird nicht berücksichtigt. Die Struktur soll jedoch eine spätere Erweiterung um diese Funktion erlauben.

ZU LÖSENDES PROBLEM

In vielen Teams ist die Qualität von Commit-Nachrichten uneinheitlich. Das führt zu:

- schwer verständlichen und schlecht wartbaren Historien

- unklaren oder zu allgemeinen Nachrichten (z. B. „fix bug“)

- fehlender Standardisierung zwischen Entwicklern

- erschwerter Nachverfolgung von Änderungen und Entscheidungen

Die traditionellen Lösungen, die auf regulären Ausdrücken oder starren Regeln basieren, ermöglichen lediglich die Überprüfung oberflächlicher Aspekte (Länge, Format, Struktur), können jedoch weder die semantische Qualität der Nachricht noch deren Verständlichkeit bewerten, was das Verständnis der Nachrichten erschwert und sich direkt auf die Arbeit der Entwickler auswirkt.

ZIEL DES SYSTEMS

Das Werkzeug soll:

- formale Regeln prüfen (Struktur, Format, Stil)

- Die semantische Qualität der Commit-Meldung bewerten und sicherstellen, dass sie nicht nur einem Format entspricht, sondern auch Sinn ergibt

- klares und umsetzbares Feedback geben

- Anpassung an verschiedene Teams durch Konfiguration durch autorisierte Benutzer ermöglichen

- zwei Validierungsstufen bieten (mit und ohne KI)

TIEFE DER ANALYSE

1. Strukturelle Analyse (deterministisch)

Logische Regeln, die den Format überprufen und nur von administrativem Personal geändert werden können, z. B.:

- Imperativform in der Betreffzeile

- maximale Länge

- kein Punkt am Ende der Überschrift

- Trennung von Titel und Beschreibung

Diese Prüfungen erfolgen ohne KI und gelten verbindlich für alle Nutzer. Nur autorisierte Benutzer können sie ändern.

2. Semantische Analyse (KI-basiert)

Es werden Aspekte (die von autorisierten Benutzern definiert werden) bewertet, die sich nicht rein logisch bestimmen lassen und für deren Bewertung ein intelligentes System erforderlich ist, z.B:

- Klarheit

- Genauigkeit

- Mehrdeutigkeit

- allgemeine Textqualität

- verwendete Sprache

Beispiele:

- „fix stuff“ → unzureichend

- „arreglar cosas“ → falsche Sprache

- „fix null pointer in login handler“ → klar und spezifisch

BEGRÜNDUNG FÜR DEN EINSATZ VON KI

KI wird eingesetzt, um Eigenschaften natürlicher Sprache zu bewerten, die durch feste Regeln nicht erfassbar sind.

Feste Regeln prüfen:

- Format

- Länge

- einfache Muster.

Sie prüfen nicht:

- Verständlichkeit

- Informationsgehalt

- Genauigkeit

- sprachliche Korrektheit.

Daher wird ein vortrainiertes Sprachmodell (LLM) über eine externe API genutzt. Dieses bewertet die Commit-Nachricht anhand definierter Kriterien und liefert eine strukturierte Antwort. Die Auswahl des konkreten Modells erfolgt später auf Basis technischer und wirtschaftlicher Analyse.

ART DER KI UND TECHNISCHE INTEGRATION

Verwendet wird ein vortrainiertes Sprachmodell über eine HTTP-API.

Ablauf:

1. Nutzer erstellt Commit

2. Git-Hook fängt die Nachricht ab

3. System führt aus:

- Regelprüfung (lokal)

- semantische Analyse (externe API)

Die API erhält:

- Commit-Nachricht

- Bewertungskriterien

- gewünschtes Antwortformat

Beispielantwort:

{

"valid_Commit": false,

"issues": ["zu allgemein", "unklar"],

"suggestion": "verbesserte Version der Nachricht"

}

Das System entscheidet:

- Commit blockieren (bei kritischen Fehlern) und Vorschläge anzeigen

- Commit zulassen, aber mit Warnung (bei nicht kritischen Fehlern)

- oder Commit zulassen

SYSTEMARCHITEKTUR

Implementierung. Module:

- CLI (Command Line Interface):

Ermöglicht die manuelle Ausführung des Systems (z. B. check, suggest, score) ohne einen Commit durchzuführen.

- Git-Integration:

Implementiert den Hook commit-msg, der die Commit-Nachricht überprüft.

- Regel-Engine:

Bewertet Regeln deterministisch.

- KI-Modul:

Verwaltet die Kommunikation mit dem externen LLM.

- Analysemodul (Orchestrator):

Kombiniert die Ergebnisse aus Regelprüfung und KI-Analyse.

- Reporting-Modul:

Erzeugt die Ausgabe für den Nutzer (Fehler, Vorschläge).

- Installationsmodul: Enthält das Skript zur Einrichtung des Werkzeugs auf dem Gerät des Nutzers.

- Konfigurationssystem: Regeln werden über eine externe Datei (YAML oder JSON) definiert.

Beispiel Konfiguration:

rules:

imperative:

value: true

critical_rule: true

max_length:

value: 72

critical_rule: true

BETRIEBSMODI

- Basis-Modus: nur Regelprüfung (Fallback ohne Internet/API)

- Erweiterter Modus: Vollständige Anaylse (Regeln + KI-Analyse)

DEPLOYMENT UND ZIELUMGEBUNG

Das Projekt wird über ein Git-Repository bereitgestellt und gepflegt.

Zielumgebung: Linux,weil:

- häufiger Einsatz im Unternehmen

- bessere Konfiguration von Git-Hooks

- effiziente CLI-Tools Ausführung

Anpassung an Windows sollte mit geringem Aufwand möglich sein.

ERWARTETES ERGEBNIS

Das System soll:

- die Qualität von Commit-Nachrichten verbessern

- einheitliche Standards schaffen

- Mehrdeutigkeit reduzieren

- direktes Feedback liefern

- erweiterbar sowie konfigurierbar sein.

ABGRENZUNG

- keine Analyse des geänderten Quellcodes

- keine Prüfung der Übereinstimmung zwischen Code und Nachricht

- Fokus ausschließlich auf der Commit-Nachricht

AlterAntrag.pdf

Der Passus: Daher wird ein vortrainiertes Sprachmodell (LLM) über eine externe API genutzt

gäbe einige Details her, die man im Antrag ausführlicher darstellten kann.

Auswahlverfahren für ein LLM ?
Was bedeutet vortrainiertes Sprachmodell? Fertig von der Stange oder eigenen Zusatztraining mit LoRA/QLoRA.
Da kann man schon mal eine ausführliche Nutzwertanalyse einbauen.
Architektur: APIs auf welcher Basis REST oder OPENAI, in welcher Sprache in welcher IDE? Auch hier kann ein Auswahlverfahren dargestellt werden.

Mach bitte nicht den Fehler zu schreiben, dass sein alles schon festgelegt oder vorgegeben.
Da muss es mindestens eine handvoll Kandidaten geben, die bewertet werden müssen.

Das ganze Thema ist für einen PA Neuland. Daher sollten hier wieder die allgemeinen Grundanforderungen an ein gutes Projekt betont werden.
Mit technischen Details kommt man noch nicht weiter.

Bearbeitet vor 4 Stunden4 h von hellerKopf

Da es BaWü ist können wieder unterschiede im Antrag sein aber allein dadurch das du keinerlei genauere Zeitplanung im Antrag hast würde es abgelehnt werden.

Das einzige was du Implementierst scheint der Git-Hook zu sein?

Bisschen sehr dünn für einen Anwendungsentwickler.. ansonsten scheint da ja nur bisschen Prompting zu sein bzw. Regeln für die KI.

Also ich sehe da ehrlich gesagt nicht wirklich etwas was für einen Anwendungsentwickler ein gutes Projekt wäre oder zeigt das du was kannst.

Sowas würde ich tatsächlich eher größtenteils bei einem FiSi oder IT-Systemkaufmann sehen.

vor 4 Stunden, malono26 hat gesagt:

Es werden Aspekte (die von autorisierten Benutzern definiert werden) bewertet, die sich nicht rein logisch bestimmen lassen und für deren Bewertung ein intelligentes System erforderlich ist, z.B:

- Klarheit

- Genauigkeit

- Mehrdeutigkeit

- allgemeine Textqualität

- verwendete Sprache

Beispiele:

- „fix stuff“ → unzureichend

- „arreglar cosas“ → falsche Sprache

- „fix null pointer in login handler“ → klar und spezifisch

Also.. ganz ehrlich.. würde sich das Problem nicht einfach dadurch lösen das ihr bei euren Commits eine Struktur vorgebt?

Wozu KI?

Der erste Satz ist übrigens ein richtiges Sahnehäubchen!

"Es werden Aspekte bewertet, die sich nicht rein logisch bestimmen lassen und für deren Bewertung ein intelligentes System erforderlich ist"

Dadurch hast du dich selbst und deine gesamte Firma als Idioten bezeichnet. Ist dir hoffentlich klar.

Bearbeitet vor 2 Stunden2 h von Brapchu