Was von der stackconf 2026 bleibt: Semantic Release, KI und eine unbequeme Frage

Tag zwei der stackconf 2026, kurz vor elf. Im Foyer nickt mir jemand zu, als hätten wir uns gestern verabredet — dabei haben wir uns zwischen den Sessions vielleicht zweimal kurz unterhalten, einmal an der Espressomaschine, einmal nach einer Q&A. Genau so fühlt sich diese Konferenz an: klein genug, dass man Leuten zweimal begegnet, groß genug, dass man jedes Mal etwas Neues mitnimmt.

Mein eigener Talk lag da bereits hinter mir: „End Release Anxiety: A Guide to Fully Automated Workflows with Semantic Release”. Fachlich ging es um automatisierte Release-Prozesse, saubere Versionierung und weniger Unsicherheit im Deployment-Alltag. Hängen geblieben ist für mich aber nicht nur der Talk selbst, sondern vor allem die Gespräche danach. Denn rund um Semantic Release tauchten schnell größere Fragen auf: Wie verändert KI unsere Open-Source-Prozesse? Wie gehen Maintainer mit AI-Slop um? Und wie bilden wir künftig Senior-Entwickler aus, wenn KI immer mehr klassische Junior-Aufgaben übernimmt?

Eine kleine Konferenz, die persönlich bleibt

Wie schon im Ankündigungsartikel angedeutet, ist die stackconf bewusst keine Massenveranstaltung. Vor Ort waren es ungefähr 60 bis 70 Teilnehmer, zwei Tage, ein Track im Studio Balan. Auf Konferenzen mit drei- oder vierstelligen Teilnehmerzahlen verschwindet das Networking oft im Tagesplan: man wechselt von Talk zu Talk, der Smalltalk in der Kaffeepause bleibt höflich-flach, und am Ende des zweiten Tages kennt man niemanden besser. Die stackconf war anders. Am zweiten Tag fühlte sich das Foyer an wie ein Workshop, in den man zufällig hineingestolpert ist — nur dass alle Anwesenden den gleichen Workshop besuchen.

Wer auf einer Konferenz tatsächlich Gespräche führen will und nicht nur Aufzeichnungen mitnehmen, ist bei der stackconf richtig. Empfehlung ohne Vorbehalt.

Mein Talk: weniger Anxiety, mehr Routine

Im Talk-Slot ging es um Conventional Commits und Semantic Release: Wie man aus manuellen Release-Ritualen einen deterministischen Prozess macht, der vom Commit bis zum veröffentlichten Artefakt durchläuft.

Was ist Semantic Release?

Semantic Release automatisiert den Weg von Commit-Nachrichten zu Versionierung, Changelog und Veröffentlichung. Aus Commit-Konventionen (feat:, fix:, BREAKING CHANGE) leitet das Werkzeug die nächste Version, den Changelog und das Release-Tag ab — vollautomatisch, ohne manuellen Eingriff. Ziel ist nicht nur Bequemlichkeit, sondern weniger Unsicherheit im Release-Prozess: keine Diskussionen mehr darüber, ob das jetzt eine 1.4.0 oder eine 1.3.5 wird.

Den fachlichen Hintergrund zu Conventional Commits und Semantic Versioning hatte ich bereits in einem eigenen Artikel zusammengeschrieben. Wer den Talk verpasst hat oder ihn gesehen hat und etwas zum Mitnehmen sucht, findet die Slides oben oder unten zum Download.

Was mich beschäftigt: Open Source unter Druck

In genau einer der Pausen kam zwischen drei Leuten am Stehtisch eine Frage auf, die mich seitdem nicht loslässt: Wie verhindern wir, dass Open-Source-Projekte am AI-Slop ersticken?

AI-Slop, also flüchtig generierter Pull-Request-Lärm — Issues, die kein Problem beschreiben, PRs ohne Kontext, generierte „Fixes”, die nichts fixen — ist auf den größeren Repositories längst Realität. Maintainer berichten von dreistelligen wöchentlichen Eingängen, deren bloße Triage mehr Zeit kostet als das eigentliche Engineering.

Das Schwierige an der Diskussion: zwischen zwei Spannungspolen entsteht kein einfacher Kompromiss.

• Auf der einen Seite stehen die offen bösartigen Absichten — Supply-Chain-Attacks, gezielte Sabotage, untergeschobene Schwachstellen. Hier möchte man hart durchgreifen, vielleicht sogar Bewerbungsverfahren für Contributors einführen.
• Auf der anderen Seite steht das Wachstum der Community — neue, weniger erfahrene Entwickler, die ihre erste Open-Source-Erfahrung machen wollen. Genau die schreckt ein hartes Filter-Verfahren ab.

Setzt man die Schranke zu niedrig, ertrinken Maintainer in PRs, die keinen Wert bringen. Setzt man sie zu hoch, stirbt die Pipeline an Nachwuchs.

Die eigentliche Herausforderung ist also nicht, KI-Beiträge zu verhindern, sondern Reibung an der richtigen Stelle einzubauen: niedrig genug für Lernende, hoch genug gegen maschinell erzeugten Müll.

AI gegen AI — pragmatisch und lehrreich

Mein Eindruck aus der Diskussion: beide Seiten lassen sich tatsächlich mit KI selbst adressieren — wenn man die richtigen Werkzeuge baut. Konkret heißt das für die AI-Slop-Flut:

• Pre-Submit-Checks, die prüfen, ob ein PR überhaupt ein verlinktes Issue adressiert oder Tests mitbringt.
• LLM-basierte Erstklassifikation: Bugfix, Feature, Noise, Duplikat, potenziell gefährlich — ein automatischer Reviewer trifft die Vorauswahl, bevor ein Mensch die Diskussion beginnt.
• Bots, die nachfordern: Reproduktionsschritte, fehlende Testabdeckung, unklare Begründung — strukturierter Einspruch statt Kommentar-Flut.
• Hinweise auf Risiken: fehlende Tests, Breaking Changes, unplausible Codepfade — automatisch markiert, manuell entschieden.

Lehrreich war an der Diskussion vor allem die Haltung dahinter: nicht reflexhaft abwehren, sondern prüfen, wie die eigenen Werkzeuge intelligenter werden können. Wer einen jungen Entwickler mit einer abfälligen Bot-Antwort begrüßt, vertreibt nicht nur AI-Slop, sondern auch Talent. Tonfall ist hier kein Soft-Skill, sondern Pipeline-Strategie.

Den zweiten Pol — die echte Sabotage — kann KI nicht alleine lösen. Da hilft kein Filter, sondern strengere Identitätsprüfung und ein bewussteres Verständnis von Vertrauen in der Community. KI kann im Hintergrund unterstützen, etwa beim Erkennen verdächtiger Code-Muster, aber die strukturelle Antwort liegt bei den Menschen.

Der unbequemere Kerngedanke bleibt: Die Open-Source-Community ist zu klein für ihre Bedeutung in der Gesellschaft. Wer diese Infrastruktur nutzt — und das tut praktisch jedes moderne Software-Projekt —, sollte zumindest verstehen, auf wessen unbezahlter Arbeit sie oft beruht.

Die unbequemere Folge: wer baut die Senior-Pipeline?

Mit dem ersten Gedanken hängt ein zweiter zusammen, der bei mir am längsten hängengeblieben ist: KI verändert die Rolle von Junior-Entwicklern fundamental. Aufgaben, die früher das tägliche Brot eines Junioren waren — kleine Features umsetzen, Bugs nachziehen, Tests schreiben — übernimmt heute zunehmend die KI-gestützte Entwicklung. Das macht den klassischen Junior-Slot ökonomisch fragwürdig.

Wenn KI die einfachen Aufgaben übernimmt, verschwindet nicht nur Arbeit. Es verschwindet auch ein Teil des Lernpfads.

Was klingt wie eine reine Effizienzgeschichte, ist eigentlich ein Pipeline-Problem. Senior-Entwickler entstehen nicht im Vakuum. Sie sind das Ergebnis einer mehrjährigen Reise durch viele Junior-Aufgaben, viele Fehler, viele Code-Reviews durch andere Senior-Entwickler. Wenn wir die Junior-Stufe wegrationalisieren, müssen wir uns in einer Dekade fragen: Woher kommen unsere Senioren eigentlich?

Der Vergleich, der mir dabei in den Kopf kam, ist COBOL. Eine Generation, die in der Hochzeit Pflichtveranstaltung für jedes größere System war, ist heute eine Nische — schwer zu finden und teuer einzukaufen. Wer Senioren in der Software-Entwicklung haben will, muss aktiv welche heranziehen. Wenn das niemand übernimmt, wird auch unser Berufsstand irgendwann zur Nische.

Das ist die unbequemere Frage, die die stackconf-Pausen für mich aufgeworfen haben — und die mich am stärksten beschäftigt: Wir müssen Lernen aktiv organisieren, statt es passiv aus dem Tagesgeschäft mitwachsen zu lassen. Mentoring, Code-Review-Kultur, bewusst geführte Lern-Aufgaben jenseits dessen, was die KI ohnehin erledigt — das wird die eigentliche Investition in die nächste Senior-Generation.

Was bleibt

Die stackconf hat mich gut abgeholt — fachlich wie atmosphärisch. Den eigenen Talk halten zu dürfen war das eine; die Diskussionen am Stehtisch das andere. Beides hat Spuren hinterlassen — vor allem aber die Frage, wie wir Software-Entwicklung als Berufsstand zukunftsfest halten.

Die Slides zum Talk liegen unten zum Download. Die Fragen, die ich aus den Pausen mitgenommen habe, beschäftigen mich vermutlich noch eine ganze Weile.