vibecoding

aus ideen werden eigene werkzeuge

Hannes Pix Eigene Projekte im LVM

01 / die kombination

Ideen entwickeln. Fortschritt behalten.

LLM + Agent

Beschreiben. Bauen. Verbessern.

Unser Beispiel: Claude Code im Web.

Git + Projektplattform

Versionieren. Prüfen. Gemeinsam arbeiten.

Demo: GitHub. Ziel im LVM: GitLab.

Der GewinnDas Projekt überlebt die einzelne Sitzung.

commits

Stände sichern

branches

Ideen getrennt testen

diffs & reviews

Änderungen verstehen

Das Sprachmodell unterstützt beim Entwerfen und Schreiben. Der Agent beziehungsweise Harness verbindet es mit Dateien und Werkzeugen. Claude Code ist unser anschauliches Beispiel. Git hält gespeicherte Änderungen als Versionsgeschichte fest. GitHub und GitLab bieten darum eine gemeinsame Projektplattform. Unser Ziel ist GitLab innerhalb der Organisation. Commits machen gespeicherte Stände nachvollziehbar; Branches erlauben getrennte Versuche; Diffs und Reviews helfen beim Prüfen. Rückgängig machen betrifft versionierte Dateien – nicht automatisch Datenbankänderungen oder externe Aktionen. Quellen: https://docs.github.com/en/get-started/using-git/about-git ; https://code.claude.com/docs/en/how-claude-code-works ; https://docs.gitlab.com/user/project/merge_requests/ . Stand: 25.09.2026.

festhalten

das wichtige bleibt im projekt

02 / über das kontextfenster hinaus

Der Chat verdichtet. Das Repo bewahrt.

Nur im Gespräch

Kontextgrenze → Kompression
Details können verloren gehen.

Im versionierten Projekt

Codeaktueller Stand

READMEZiel & Einstieg

ProjektnotizenEntscheidungen & nächste Schritte

Neuer Chat. Derselbe gesicherte Stand.

Git vergrößert kein Kontextfenster. Wissen muss als Datei festgehalten und erneut gelesen werden.

Claude Code verdichtet den Gesprächsverlauf bei wachsendem Kontext; frühe Detailanweisungen können dabei verloren gehen. Auch ein Agent mit Git hat weiterhin ein begrenztes Kontextfenster. Der Vorteil liegt außerhalb davon: versionierte Dateien und eine nachvollziehbare Historie. Unsere Arbeitsweise: Ziel und Startanleitung in README, wichtige Entscheidungen und offene Aufgaben in kurzen Projektnotizen festhalten und gemeinsam mit dem Code committen. Ein neuer Agent muss die relevanten Dateien aktiv lesen; der gesamte alte Chat wird nicht automatisch übertragen. Je nach Werkzeug ergänzen CLAUDE.md oder AGENTS.md die Anweisungen. Die Dateien müssen aktuell gehalten werden. Quellen: https://code.claude.com/docs/en/how-claude-code-works ; https://code.claude.com/docs/en/memory ; https://opencode.ai/docs/rules/ . Stand: 25.09.2026.

frei bleiben

das projekt gehört in unsere hand

03 / werkzeuge sind austauschbar

Anderer Agent. Dasselbe Projekt.

Agent / Harness

Claude Code
OpenCode …

Sprachmodell

Nach Aufgabe,
Unterstützung und Freigabe.

unser repo

Code · Wissen · Historie

Ziel: internes GitLab

Neuer Agent liest den Stand. Wir arbeiten weiter.

Modellwahl und automatische Anweisungsdateien hängen vom jeweiligen Werkzeug ab.

Harness bezeichnet hier die Arbeitsumgebung, die das Modell mit Dateien und Werkzeugen verbindet. Die Git-Dateien sind unabhängig davon bearbeitbar. Claude Code verwendet Claude-Modelle; OpenCode unterstützt mehrere Anbieter und auch lokale Modelle. Freie Wahl bedeutet deshalb nicht, dass jedes Modell in jedem Harness funktioniert. Zugänge, Integrationen, Freigaben und spezielle Anweisungsdateien müssen zum Werkzeug passen. Unser Übergabeprinzip: Änderungen sichern, Stand und nächste Schritte dokumentieren, neues Werkzeug auf dasselbe Repository zugreifen und relevante Dateien lesen lassen. Git überträgt weder die vollständige Sitzung noch automatisch Plattformfunktionen wie Issues und Berechtigungen. Die organisatorische Folgerung ist unser Vorschlag: ein internes GitLab als gemeinsamer Projektort. Quellen: https://code.claude.com/docs/en/how-claude-code-works ; https://opencode.ai/docs/providers/ ; https://opencode.ai/docs/rules/ ; https://docs.gitlab.com/user/project/ . Stand: 25.09.2026.

bauen

ein auftrag. eine änderung. eine prüfung.

04 / so läuft eine runde

Beschreiben. Ausprobieren. Freigeben.

Veröffentlichte Claude-Code-Web-Demo: Dateiänderung, Tests, Arbeitsbranch und Create PR. — Claude Code · Änderung auf eigenem Branch

GitHub in der veröffentlichten Demo: geöffneter Pull Request mit Zusammenfassung, Commits, Checks und Files changed. — GitHub · Pull Request zur gemeinsamen Prüfung

Die KI arbeitet mit. Wir entscheiden, was bleibt.

Öffentliche Produktdemo, 10/2025 · Tessl · kein LVM-Projekt, keine LVM-Daten

Beispielauftrag: „Baue eine kleine Vorgangsübersicht mit Status und Suche. Zunächst mit Beispieldaten.“ Für den gezeigten Web-Workflow: GitHub-Repository anlegen, in claude.ai/code GitHub verbinden und das Repository auswählen. Bei Bedarf erst den Plan besprechen. Claude setzt die Änderung auf einem Branch um. Danach selbst ausprobieren, konkrete Fehler zurückmelden und erneut testen. Den Diff prüfen und einen Pull Request öffnen. Vor dem Merge Funktion, Änderungsumfang und vorhandene Checks ansehen. In GitLab heißt der entsprechende Vorschlag Merge Request. Erst ein eingerichteter, freigegebener Deployment-Schritt bringt die Anwendung in den Betrieb. Die Screenshots zeigen das öffentliche Demo-Projekt acme/tea-sales, nicht unsere beispielhafte Vorgangsübersicht. Bilder: unveränderte Frames 0 und 85 der veröffentlichten GIF-Demo „Creating a PR in Claude Code“, Tessl, 22.10.2025: https://tessl.io/blog/anthropic-brings-claude-code-to-the-web-and-mobile . Workflow: https://code.claude.com/docs/en/web-quickstart ; https://docs.gitlab.com/user/project/merge_requests/ . Stand: 25.09.2026.

betreiben

eigene anwendungen. interne daten.

05 / vorgeschlagenes zielbild

Code braucht einen Ort zum Laufen.

LVM · interne Betriebsumgebung

Projektstand

GitLab

Code + Wissen

freigegebenes
Deployment

Anwendung

Container

eigene Fachwerkzeuge

geregelter
Datenzugriff

Datenhaltung

DB-Server

Produktivdaten

Test und Produktion trennen. Betrieb und Zugriffe verantworten.

Interne Datenhaltung bedeutet nicht automatisch interne KI-Verarbeitung.

Vorgeschlagen ist eine intern betriebene Umgebung für eigene Anwendungen: GitLab für Code und Projektdokumentation, eine Container-Laufzeit für die Anwendung und ein betreuter Datenbankdienst für persistente Daten. Die konkrete Plattform und Datenbank wählt der Betrieb passend zu vorhandenen Standards. Der Datenbankdienst muss nicht selbst im selben Container laufen. Für einen Pilot braucht es geklärte Identitäten und Rechte, getrennte Test- und Produktionsumgebungen, geschützte Zugangsdaten, persistente Speicherung, Backups mit Wiederherstellbarkeit sowie Zuständigkeit für Updates und Überwachung. Container allein sind keine Freigabe für Produktivdaten. Entwicklung zunächst mit synthetischen oder freigegebenen Testdaten; Produktivdaten nur im genehmigten Betrieb und mit erforderlichen Rechten. Ein externer LLM-Dienst kann trotz internem GitLab oder lokalem Agenten über Prompts, Dateiinhalte oder Logs Daten erhalten. Deshalb Modellendpunkt und erlaubte Datenflüsse ausdrücklich freigeben und technisch begrenzen. Weder Git noch ein Code-Rollback ersetzt Datenbank-Backups oder eine Migrationsstrategie. Dieses Zielbild ist ein Vorschlag für die Abstimmung mit dem zuständigen Betrieb, keine geprüfte LVM-Sicherheitsarchitektur.

ermöglichen

vom prototyp zum nutzbaren werkzeug

06 / was wir jetzt brauchen

Eine Basis für eigene Projekte.

am dringendsten

Container
+ Datenbank

Eigene Anwendungen mit
Produktivdaten intern betreiben.

die gemeinsame grundlage

Internes
GitLab

Code, Projektwissen und
Freigaben gemeinsam halten.

Start: ein Pilotprojekt mit klarer Betriebsverantwortung.

Mein Vorschlag für die Verwaltung: Ein gemeinsames internes GitLab für eigene Projekte bereitstellen und mit höherer Dringlichkeit eine betreute Container- und Datenbankumgebung ermöglichen. Ein Pilot sollte an einem konkreten internen Bedarf starten, mit Fachverantwortung, Betriebsverantwortung und einer klar abgegrenzten Datenfreigabe. Zuerst mit Beispieldaten nachweisen, dass Funktion, Bereitstellung und Wiederherstellung funktionieren; danach den Einsatz mit freigegebenen Produktivdaten ermöglichen. Das Ziel ist ein tatsächlich nutzbares und weiterentwickelbares Werkzeug. LLM plus Git erleichtert die Entwicklung und Übergabe. Die interne Plattform macht daraus einen nachhaltigen Betrieb. Zuständigkeiten, Ressourcen und technische Standards sind noch zu vereinbaren; diese Folie behauptet keine bereits erteilte Freigabe.

Danke

fragen · ideen · nächste schritte