10:43 Uhr

Vier Teams. Zwei Tage. 31 eingereichte Ideen. Und exakt ein Case, für den sich am Ende alle unabhängig voneinander entschieden haben. Herausgekommen sind vier lauffähige Lösungen mit vier unterschiedlichen Ansätzen. Und eine sehr klare Erkenntnis: Wir sind deutlich besser darin geworden, KI produktiv einzusetzen – nicht nur individuell, sondern als Team. Ein Einblick in das Camp 2026 – und darin, wie wir heute bei SYZYGY Techsolutions mit KI arbeiten.

Alle drei Camps davor hatten ein gesetztes Thema: 2023 Generative AI, 2024 RAG für unsere Knowledge Base, 2025 AI Agents. Diesmal nicht. Die Aufgabe lautete nur: Ideen für die Weiterentwicklung von SYZYGY Techsolutions (STS). Für alle Bereiche, Hackathon-Format, Code optional. KI ausdrücklich nur als Werkzeug – kein vorgegebener Tech-Stack, kein gesetztes Tooling.

Die Ideen kamen von den Teilnehmenden selbst: Sie sendeten vorher insgesamt 31 Pitches ein, aus denen wir nach Machbarkeit, STS-Bezug und Camp-Kompatibilität gefiltert und zehn potenziell umsetzbare Cases in fünf Kategorien konsolidiert haben: Wissen & Assistenten, Delivery & Projektsteuerung, Business Development, Ressourcen & Zeit, Kultur & Experience.

… Und dann nahmen alle denselben.

Alle vier Teams wählten als Pitch-Thema den SYZYGY Skill-Finder.

Das Problem ist nicht neu: Bei STS steckt enorm viel Wissen in den Köpfen der Mitarbeitenden – aber wer was weiß, weiß niemand so genau. Ein Team hat drei Beispielfragen formuliert, die das Problem ziemlich treffend auf den Punkt bringen:

• „Wer kann Backend, ist aktuell verfügbar und mag Menschen?“
• „Wer ist Senior genug für den Pitch und sitzt nicht nur dabei, um random Tipps zu geben und Kaffee zu trinken?“
• „Wer hat Automotive-Erfahrung, und das nicht nur vom eigenen Leasingvertrag?“

Genau hier setzt der Skill-Finder an: Statt in Teams-Channels, bei Delivery, Vorgesetzten, HR usw. herumzufragen, sucht man im Skill-Finder nach Skills, Technologien und Erfahrungen und findet direkt die passenden Kolleg:innen.

Dass alle vier Teams ohne Absprache dasselbe Problem gewählt haben, war eher Befund als Zufall. Entsprechend war die Priorisierungsdiskussion in allen Teams vor der ersten Kaffeepause erledigt. Ein Nebeneffekt des gemeinsamen Themas: Weil alle vom gleichen Startpunkt losliefen, wurde sichtbar, wie unterschiedlich vier Teams dasselbe Problem angehen. Aus einem Hackathon wurde so ein Methodenvergleich.

Am zweiten Nachmittag hatte jedes Team 25 Minuten für den Pitch. Die Vorgaben waren knapp: Team und Lösung vorstellen, Erfahrungsbericht und Erkenntnisse aus den zwei Tagen – und dazu der Satz, der in solchen Briefings mehr bewirkt als jede Gliederung: „Lasst euch was einfallen.“ Entsprechend unterschiedlich fielen die vier Auftritte aus.

Team A hat sich am weitesten vom klassischen Suchfeld gelöst. ASSMBLR fragt nicht nach Skills, sondern nach der Mission: Man beschreibt in natürlicher Sprache, was zu tun ist, ein LLM übersetzt das in Skills, Rollen, Zeiträume und Verfügbarkeiten – editierbar, nicht als Blackbox. Daraus entsteht keine Trefferliste, sondern ein begründeter Teamvorschlag inklusive Abdeckung, offener Lücken und gemeinsamer Verfügbarkeit. Kandidat:innen lassen sich per Swipe prüfen und in einen Warenkorb legen, das Ergebnis wird als Shortlist gespeichert.

Technisch war das der ambitionierteste Beitrag: React/TypeScript im Frontend, Kotlin und Ktor im Backend, PostgreSQL als Persistenz, das LLM serverseitig angebunden – mit dem ausdrücklichen Prinzip, keine KI-Ergebnisse im Frontend zu simulieren und keine Profilinformationen zu erfinden. Kein Klickdummy, sondern eine laufende Anwendung, für die Jury mobil aufrufbar per QR-Code.

Den Award gab es allerdings für etwas anderes: für einen echten Pitch mit Story, Mission und Verkaufsdramaturgie bis zum Schluss – inklusive Preisschild, Liefertermin und einem „Best and final offer“. Wer seinen PoC am Ende der 25 Minuten tatsächlich verkaufen will, hat sich den Award „Bester Pitch“ redlich verdient.

Team B hat sich zuerst auf Use Cases festgelegt und danach nie mehr über Features gestritten. Drei Szenarien trugen die ganze Lösung:

• Staffing: passende Menschen finden und eine strukturierte Anfrage an die Teamleitung stellen.
• UnBlocking Dev: Wer seit zwei Stunden an einem kryptischen Bug klebt, findet gefilterte, gerade verfügbare Expert:innen im Haus, die schneller sind als Stack Overflow.
• Ausschreibungen: Profile und Zertifikatsnachweise auf Knopfdruck, aktuell, im richtigen Format, auf Wunsch anonymisiert.

Das Vorgehen war Mini-Scrum im Zeitraffer: Ideen im Ausschlussverfahren eingegrenzt, erster Prototyp mit Figma Make, danach User Story → Prototyp-Erweiterung → Review → Repeat. Der erste lauffähige Prototyp stand bereits um 10:43 Uhr am ersten Tag. Dafür gab es mit Fug und Recht den Award „Schnellster PoC“.

Noch bemerkenswerter als das Tempo waren die Erkenntnisse des Teams. Fokus is key: Weniger Features waren oft die bessere Entscheidung. Und: Die gemeinsame Konsolidierung der Ideen auf drei Use Cases, dann die iterative Weiterentwicklung der Lösung entlang genau dieser Use Cases – diese Reihenfolge war richtig und wichtig.

Team C hat den Case nicht neu gebaut, sondern angedockt: NerdRadar erweitert unseren bestehenden Tech Radar um Menschen. Gleiche visuelle Sprache, aber Erweiterungen an allen Stellen, darunter neue Quadranten und Ringe. Im NerdRadar stehen die Blips jetzt auch für Kompetenzen im Haus (eingrenzbar auf Mitarbeiter:innen, Teams oder Projekte). Zusätzlich zeigen gelb hervorgehobene Blips Weiterbildungs-, Weiterentwicklungs- oder gar Verkaufsoptionen in Gesprächen mit Kund:innen. Dafür gab es den Award „Best Brand Fit“.

Demonstriert wurde entlang von drei realistischen Fällen: eine Ausschreibung, die TYPO3 fordert; jemand mit Accessibility- und React-Erfahrung, kurzfristig zu 20–30 % verfügbar; ein komplettes Automotive-Pitch-Team aus Consulting, UX, Frontend und Backend. Dazu angedachte Anbindungen an HR- und Accounting-Tools sowie Ticketing-Tools, Wikis und Co.

Das Vorgehen: gemeinsames Brainstorming, Features im Plan-Modus definiert, der Plan von der KI ausführen lassen – und dann das ehrlichste Finding des Camps: Das Ergebnis war alles andere als vollständig. Deswegen änderte das Team den Modus. Die Tasks wurden in kleinere Features heruntergebrochen und einzeln per „Mob Vibe Coding“ mit Marvin als Driver gepromptet. Selbst geschrieben wurde keine Zeile Code.

Team D hat den Weg gewählt, der unseren echten Projektprozessen am nächsten kommt – und ihn im Pitch Schritt für Schritt offengelegt. Vom FigJam-Brainstorming zu Wireframes, aus den Wireframes per Screenshot ein Figma-Make-Prototyp.

Das Urteil des Teams über dieses Zwischenergebnis: „Okay, aber das ist doch nicht STS!“ Sowohl Design als auch Funktionalität waren „okay(ish), aber nicht ausreichend“. Deswegen wurde der Code aus dem Prototyp per Agents geprüft und per GitHub Copilot Agents neu aufgesetzt. Das Design wurde reverse-engineered zurück nach Figma kopiert und für den Feinschliff wurden Figma Agents auf eine klare Mission geschickt: „Make Figma Make Enterprise Ready“. Anschließend wurden auf dem neu strukturierten Code per GitHub Copilot CLI (bzw. GitHub Copilot Desktop) Figma MCP für KI-gesteuerte Design-Anpassungen und automatische visuelle Validierung über Playwright eingesetzt.

So wurde aus einer „okayishen“ Lösung mit einer einzigen App.tsx und So-la-la-Design eine wartbare, vollständige, SYZYGY-CI-konforme Lösung, weitgehend blind mit KI entwickelt. Inklusive Profilseiten, Skill-Importer, Siggy-Integration und einer Speed-Dating-Funktion für technologisch Gleichgesinnte. Award: „Best Process & Efficiency“.

Einige Learnings des Teams: Manche manuelle Änderung ist nach wie vor deutlich schneller als ein Prompt (und spart nebenbei AI Credits ;-)). Figma MCP, enorm schnelle Ergebnisse, enormes Potenzial, wenn Rahmen und Harness stimmen – und: „Alle Gewerke gleichzeitig rennen lassen funktioniert nicht. Surprise!“

Zurück auf Anfang: Neben Prompts und Prototypen ging es beim Camp natürlich auch ums Miteinander – und wie jedes Jahr hat das sehr gut funktioniert.

Der erste Morgen begann für die 20 Teilnehmer:innen aus Consulting, Delivery, Kreation und Technology mit dem Warm-up „Wer steht als Letztes“: Alle stehen auf, dann kommen Fragen nach dem Muster „Bleib stehen, wenn …“. Trifft zu: stehen bleiben. Trifft nicht zu: setzen. Wer als Letzte:r steht, gewinnt die Runde.

Die Fragen waren im Kern Geständnisse mit Publikum. Bleib stehen, wenn du an einer Tür schon mal gezogen hast, auf der groß „Drücken“ stand. Wenn du eine Pflanze auf dem Gewissen hast – mindestens eine. Wenn dein Passwort mal der Name eines Haustiers war, womöglich mit einer 1 dahinter, damit es sicher ist. Und, für eine Firma dieses Namens durchaus eine echte Prüfung: wenn du weißt, was „SYZYGY“ eigentlich bedeutet.

Stattgefunden hat das alles zum ersten Mal nicht im Collegium Glashütten – das wird ein halbes Jahr umgebaut –, sondern im Tagungshotel der Lufthansa in Seeheim-Jugenheim, rund 45 Minuten südlich von Bad Homburg. Der unfreiwillige Wechsel hat sich gelohnt: ein sehr schicker Ort mit allen Zutaten, die ein Camp braucht: ausreichend Platz, drei klimatisierte Räume mit Blick und Zugang zum Grünen, professionelle Medientechnik, jederzeit Kaffee, Tee, Snacks & mehr rund um die Uhr. Das Essen war vorzüglich und die Bar riesig – wovon wir uns am ersten Abend selbst überzeugten.

So viel zum Drumherum. Zurück zu den vier Teams und der Frage, was sich aus ihren unterschiedlichen Ansätzen lernen lässt.

Nebeneinandergelegt ergeben die vier Lösungen ein ziemlich klares Bild:

• Eine gute Planung bestimmt das Ergebnis. Wer bei den Use Cases anfängt, ist mittags fertig. Wer einfach loslegt, hat abends noch nichts Lauffähiges.
• Große Prompts funktionieren selten wie geplant. Zwei Teams sind unabhängig voneinander an derselben Stelle angekommen: Ein Plan, den die KI am Stück ausführen soll, wird nicht vollständig ausgeführt. Kleiner schneiden und iterativ vorgehen hilft.
• Schön ist nicht gleichbedeutend mit wartbar. Zwei Teams berichten dasselbe: Das Ergebnis sieht sofort gut aus und ist strukturell trotzdem eine einzige große Datei. Der Weg von „sieht nice aus“ zu „kann man betreiben“ ist die eigentliche Arbeit.
• Mehr Tools hätten keinen Unterschied gemacht. Die vorhandene KI-Toolchain bei STS hat für alle vier Lösungen ausgereicht – und kein Team brauchte alles, was zur Verfügung stand. Entscheidend waren vielmehr die Prozesse dahinter: Anforderungen schärfen, Aufgaben sinnvoll schneiden, Ergebnisse prüfen und den Ansatz wechseln, wenn etwas nicht funktioniert. Damit bestätigt sich einmal mehr: „Es sind nie die Tools, es sind immer die Menschen und Prozesse.“

Und noch etwas ist aufgefallen: Der Skill-Finder wurde schnell größer als sein ursprünglicher Use Case. In den vier Lösungen ging es längst nicht mehr nur darum, die richtigen Kolleg:innen zu finden. Ressourcenplanung, Ausschreibungsunterstützung, Onboarding, die Erweiterung von Siggy – unserem internen KI-Assistenten –, Gamification, Tech Radar und interne Vernetzung: Aus einer gemeinsamen Ausgangsidee entstanden Ansätze für viele der anderen Cases – und damit für ganz unterschiedliche Bereiche bei uns.

Ob und welche Teile davon ihren Weg in unseren Alltag finden, wird sich in den nächsten Wochen zeigen. Einen Post dazu gibt es, sobald der erste Prototyp echte Profile durchsucht statt Testdaten – stay tuned.

2023 Generative AI, 2024 RAG, 2025 Agenten – und 2026 kein vorgegebenes Thema. Herausgekommen sind trotzdem, oder gerade deswegen, tolle Ergebnisse. Drei Dinge nehmen wir mit:

Die Geschwindigkeit ist eine andere. Im Vergleich zu den Camps davor ist der Sprung deutlich. Ein lauffähiger Prototyp vor der ersten Mittagspause war vor einem Jahr der Zweitages-Zielzustand. Selbst geschrieben wurde dabei so gut wie kein Code – gearbeitet wurde an Anforderungen, Plänen, Reviews und Architekturentscheidungen.

Nichts davon lief ohne Menschen. Anforderungen schärfen, Aufgaben schneiden, Reviews machen, entscheiden, was wegfällt. Nur Tippen war nicht mehr nötig. Ein Satz aus den Erkenntnissen eines Teams taugt als Zusammenfassung: KI kann viel, aber nicht alles. Bekannte Herausforderungen bleiben – z. B. Zieldefinition, Qualitätsmanagement, Integration und Infrastruktur. Nur kommt man inzwischen deutlich schneller an den Punkt, an dem sie sichtbar werden.

Im Vergleich zu den vorherigen Camps wird deutlich: Wir sind deutlich besser darin geworden, KI sinnvoll einzusetzen. Nicht nur bei einzelnen Entwickler:innen, sondern in der Breite und in der Qualität. KI hat sich von der individuellen Nutzung zum Team-Skill entwickelt. Compliance, Governance und Betriebsthemen wurden konsequent mitgedacht. Genauso wie Token Economics, Ethik und Security. Bei allen Teams zeigte sich, dass sie auf Erfahrungen aus der bisherigen Arbeit mit KI zurückgreifen konnten: wann ein Ansatz kippt, wann ein Strategiewechsel nötig ist, wann eine Aufgabe zu groß für einen Prompt ist und wann Refactoring und Context Engineering unvermeidlich werden.

Das nächste Camp hat damit eine unbequeme Messlatte: Wenn ein lauffähiger Prototyp vor der Mittagspause der neue Normalfall ist – was probieren wir 2027 aus? … Ich freu’ mich drauf!

Die Camps davor: STS Camp 2025 – Agents@Work · STS Camp 2024 – Knowledge Base 2.0 mit RAG · Tech Camp 2023 – Generative AI First