Am 29. Oktober kamen 32 Leute zu JetBrains München, um auf dem eigenen Laptop eine Software Factory zu bauen: eine Crew aus Claude-Code-Sessions im Hintergrund, die einen kleinen Auftrag vom kurzen Interview bis zu gemergten Pull Requests auf main bringt. Armend Avdijaj und Kiran Nambiar von GlassFlow haben den Workshop geleitet. Der Rückblick fasst zusammen, was am Abend passiert ist und wie sich der Workshop zu Hause nachbauen lässt.

Eine Crew aus Claude-Code-Sessions

Die Aufgabe des Abends war eine Software Factory auf dem eigenen Laptop und mit dem eigenen Claude-Plan: Claude-Code-Sessions im Hintergrund mit einem Orchestrator, einem Builder und einem Reviewer. Der Orchestrator nimmt geplante Projekte auf und startet Builder. Ein Builder arbeitet die Tickets im Repo ab, ein Pull Request pro Ticket, und der Reviewer prüft jeden Pull Request vor dem Merge. Die Spezifikation, die Tickets, die Reviews und die Antworten auf die Fragen der Crew hält Tares fest, das Open-Source-Werkzeug von GlassFlow.

Der Testauftrag war ein Click Counter für einen Link Shortener. Vom kurzen Interview bis zu den Pull Requests, die auf main gemergt waren, lief alles durch die Crew.

Das Einrichten dauerte für viele länger als geplant, vor allem wegen der Berechtigungsabfragen in Claude Code, wie Kiran anmerkte. Ein praktischer Hinweis von den Tischen: Branch Protection auf privaten GitHub-Repos gibt es nur mit einem bezahlten Plan.

Automatisierungsstufen von L1 bis L5

Kiran hat fünf Stufen beschrieben, auf denen sich eine Crew betreiben lässt. L1 schreibt Code ohne Commit, L2 committet lokal auf einem Branch, L3 öffnet Pull Requests, L4 merged auf main, und L5 deployt nach Produktion. Für L5 benutzt er den Begriff „dark factory“.

GlassFlow betreibt intern L4. L5 läuft dort nur für die Bug-Triage, mit Slack und einem Menschen in der Schleife. Für Hobbyprojekte empfiehlt Kiran L5, bei Produktion ist er skeptisch.

Aus der eigenen Produktion nannte er die Portierung einer Web-App in Go und React auf eine native Desktop-App in TypeScript, mit rund 270 Tickets.

Fragen und Antworten

Im Q&A ging es um Konflikte, Tests und Kontext. Nur Builder schreiben Code, jeder in einem eigenen Git-Worktree. Entstehen bei paralleler Arbeit Konflikte, findet ein Helfer-Agent die Merge-Reihenfolge. Ein Hook auf git push lässt nur die Reviewer-Session nach GitHub pushen. Die Tests laufen lokal beim Reviewer und in der CI.

Das Memory hält den Kontext der Organisation und die Regeln pro Projekt, geteilt oder persönlich. Ein gemeinsames Kontext-Repo für alle Sessions hat GlassFlow ausprobiert, es war schnell veraltet.

Observability für Agenten

Danach hat GlassFlow Rius gezeigt, ihre Observability für Agenten. Das Werkzeug hat vordefinierte Alerts für stille Fehler: eine Tool-Schleife mit immer gleichen Argumenten, ein wiederkehrendes Fehlermuster, auf das niemand reagiert, verschluckte Fehler und Context Rot durch aufgeblähte MCP- oder Tool-Antworten. Ein verschluckter Fehler ist zum Beispiel eine Antwort mit einer Zahl, ohne dass ein Tool-Aufruf diese Zahl geholt hat.

Bei Auto-Compaction zeigt es, was dabei weggefallen ist. Die Inhaltserfassung lässt sich abschalten. Tool-Aufrufe bleiben dann sichtbar, Prompts und Antworten sind ausgeblendet.

Eine Beobachtung zur Factory

Am Abend kam die Frage auf, was eine Factory gegenüber einer einzelnen Orchestrator-Session mit Subagents zusätzlich bringt.

Dazu habe ich eine Beobachtung. In der Factory setzen Tares und Hooks die Reihenfolge der Schritte, die Übergaben und die Prüfpunkte außerhalb des Modells durch. Bei einer einzelnen Orchestrator-Session hängt es davon ab, dass das Modell sie einhält. Der Hook auf git push, der nur den Reviewer pushen lässt, ist ein konkretes Beispiel.

Wer agentic engineering mit Claude Code im Team betreibt, kann daraus eine Prüffrage für das eigene Setup ableiten. Welche Schritte erzwingt etwas außerhalb des Modells, und welche bleiben dem Modell überlassen?

Nachbauen und Ausblick

Der ganze Workshop steht öffentlich auf https://workshop-munich.glassflow.ai/ und lässt sich zu Hause nachbauen. Tares ist Open Source: https://github.com/glassflow/tares

Der AI-SRE-Bonus wandert in eine Build-Session per Zoom, die GlassFlow später anbietet, der Termin steht noch nicht fest. Alle im Raum konnten vor Ort per QR-Code 50 US-Dollar Claude-API-Credits einlösen.

Danke an JetBrains München für die Gastfreundschaft und die Getränke, an Armend und Kiran für den Workshop und an alle, die da waren. Claude Community x GlassFlow · Supported by Anthropic · Venue: JetBrains München

Häufige Fragen

Kann ich den Workshop zu Hause nachbauen?

Ja. Auf https://workshop-munich.glassflow.ai/ stehen alle Teile. Teil 1, die Software Factory, dauert laut Anleitung etwa 30 Minuten. Er läuft auf Claude Code mit einem Plan, der Hintergrund-Sessions erlaubt, einen Anthropic-API-Key braucht er nicht. Die Einrichtung steht auf der Seite „Before you come“. Für den Bonus-Build mit dem AI SRE braucht ihr Docker und einen eigenen Anthropic-API-Key. Branch Protection auf privaten GitHub-Repos gibt es nur mit einem bezahlten Plan.

Wann gibt es den AI-SRE-Build?

GlassFlow führt ihn später als Build-Session per Zoom durch, der Termin steht noch nicht fest. Die Anleitung steht schon jetzt auf https://workshop-munich.glassflow.ai/.

On 29 October, 32 people came to JetBrains München to build a software factory on their own laptops: a crew of Claude Code sessions in the background that takes a small job from a short interview to pull requests merged on main. Armend Avdijaj and Kiran Nambiar from GlassFlow ran the workshop. This recap covers what happened on the evening and how to redo the workshop at home.

A crew of Claude Code sessions

The task for the evening was a software factory on your own laptop and your own Claude plan: Claude Code sessions in the background with an orchestrator, a builder and a reviewer. The orchestrator picks up planned projects and starts builders. A builder works the tickets in the repo, one pull request each, and the reviewer checks every pull request before it is merged. The spec, the tickets, the reviews and the answers to the crew's questions are kept in Tares, GlassFlow's open-source tool.

The test job was a click counter for a link shortener. From the short interview to the pull requests merged on main, the crew ran the whole loop.

Setup took longer than planned for many, mostly because of permission prompts in Claude Code, as Kiran pointed out. One practical tip from the tables: branch protection on private GitHub repos needs a paid plan.

Automation levels from L1 to L5

Kiran described five levels at which a crew can run. L1 writes code without a commit, L2 commits locally on a branch, L3 opens pull requests, L4 merges to main, and L5 deploys to production. He calls L5 the "dark factory".

GlassFlow runs L4 internally. L5 runs there only for bug triage, with Slack and a human in the loop. Kiran recommends L5 for hobby projects and is sceptical about production.

From their own production work he mentioned porting a web app in Go and React to a native desktop app in TypeScript, with about 270 tickets.

Questions and answers

The Q&A covered conflicts, tests and context. Only builders write code, each in its own git worktree. When parallel work conflicts, a helper agent finds the merge order. A hook on git push lets only the reviewer session push to GitHub. Tests run locally at the reviewer and in CI.

Memory holds the organisation's context and per-project rules, shared or personal. GlassFlow tried a shared context repo for all sessions, and it went stale fast.

Observability for agents

After that, GlassFlow showed Rius, their observability for agents. It has predefined alerts for silent failures: a tool loop with the same arguments, a consistent error pattern nobody acts on, swallowed errors and context rot from bloated MCP or tool results. A swallowed error is, for example, an answer with a number although no tool call fetched that number.

On auto-compaction, it shows what was dropped. Content capture can be switched off. Tool calls then stay visible, and prompts and answers are hidden.

An observation on the factory

A question came up on the evening: what does a factory add over a single orchestrator session with subagents?

I have one observation on that. In the factory, Tares and hooks enforce the order of steps, the handovers and the gates outside the model. In a single orchestrator session, they depend on the model keeping to them. The hook on git push that lets only the reviewer push is one concrete example.

Anyone doing agentic engineering with Claude Code in a team can turn this into a check for their own setup. Which steps does something outside the model enforce, and which are left to the model?

Redo it and what comes next

The whole workshop is public at https://workshop-munich.glassflow.ai/ and can be redone at home. Tares is open source: https://github.com/glassflow/tares

The AI SRE bonus build moves to a Zoom build session that GlassFlow will run later, date to be announced. Everyone in the room could claim $50 in Claude API credits on site via a QR code.

Thank you to JetBrains München for hosting us and for the drinks, to Armend and Kiran for the workshop, and to everyone who came. Claude Community x GlassFlow · Supported by Anthropic · Venue: JetBrains München

Frequently asked questions

Can I redo the workshop at home?

Yes. All parts are on https://workshop-munich.glassflow.ai/. Part 1, the software factory, takes about 30 minutes according to the guide. It runs on Claude Code with a plan that allows background sessions and needs no Anthropic API key. The setup is on the page "Before you come". For the AI SRE bonus build you need Docker and your own Anthropic API key. Branch protection on private GitHub repos needs a paid plan.

When is the AI SRE build?

GlassFlow will run it later as a build session on Zoom, and the date is still to be announced. The guide is already on https://workshop-munich.glassflow.ai/.