kuechenserver.org

Author: Christian Krakau-Louis

  • Perpetuum mobile: Wie Copilot Copilot startet, um ganze Roadmaps abzuarbeiten

    Ich bin als diplomierter Informatiker vor allem eins: faul.

    Das klingt jetzt vielleicht erstmal nicht nach dem Satz, mit dem man in ein Bewerbungsgespräch gehen sollte, aber ich halte das im technischen Kontext für eine ganz hervorragende Eigenschaft. Nicht diese “ich lasse alles liegen und hoffe, dass jemand anders den Müll rausbringt”-Faulheit. Eher diese andere. Die nützliche. Die, bei der man sich denkt: Wenn ich das dreimal machen muss, kann ich auch gleich zwei Stunden investieren, damit ich es nie wieder machen muss.

    Nun.

    Ganz so einfach ist es natürlich nie.

    Ich mag es nämlich nicht nur bequem, ich mag auch, wenn Dinge gut laufen. Und das ist eine ungünstige Kombination, weil “gut laufen” meistens bedeutet, dass man sich vorher ein paar Gedanken machen muss. Man kann Dinge natürlich auch einfach irgendwie zusammenklicken, bis sie zufällig funktionieren, aber dann hat man später diese schöne Situation, in der man um 23:47 Uhr auf ein Dashboard starrt und flüstert: “Warum bist Du so?”

    Programmieren konnte ich dabei nie besonders gut. Jedenfalls nicht in dem Sinne, in dem Menschen programmieren können, die am Wochenende aus Versehen einen Compiler schreiben, weil ihnen beim Kaffee langweilig war. Ich war immer eher der Typ: Ich weiß ziemlich genau, wie die Software sich verhalten sollte, ich weiß auch, warum die vorhandene Software das natürlich wieder nicht tut, und ich habe dann eine sehr ausgeprägte Meinung dazu, wie eine kleine Individualsoftware aussehen müsste, die das Problem elegant aus der Welt schafft.

    Das Problem daran: Irgendwer muss diese Individualsoftware dann bauen.

    Früher war dieser Irgendwer oft ich. Mit unterschiedlichem Erfolg. Es gab funktionierende Dinge, es gab Dinge, die eher Charakter hatten, und es gab Dinge, die man nachträglich nur mit “war halt 2004” entschuldigen kann.

    Heute gibt es Copilot, Codex und die ganze Familie der fleißigen Textwahrscheinlichkeitsmaschinen. Und damit entsteht eine interessante neue Form der Faulheit: Man schreibt nicht mehr zwingend jeden Code selbst, sondern man beschreibt ziemlich genau, was als nächstes passieren soll, lässt einen Agenten loslaufen, schaut sich das Ergebnis an, meckert bei Bedarf und merged, wenn es tut.

    Neudeutsch heißt das dann gerne Vibe Coding. Man hat eine Idee, redet ein bisschen mit ChatGPT darüber, bekommt eine Roadmap, lässt sich Issues daraus schneiden und fühlt sich für ungefähr sieben Minuten wie ein sehr effizienter Produktmanager mit eigenem Maschinenraum.

    Das ist auch gar nicht falsch. Es ist sogar ziemlich gut.

    Nur kommt danach der langweilige Teil.

    Denn wenn die Roadmap einmal da ist, liegen da plötzlich zwanzig, dreißig oder fünfzig Issues herum. Alle sehen irgendwie sinnvoll aus. Viele davon stammen ohnehin aus demselben ChatGPT-Gespräch. Und jetzt soll ich als Mensch ernsthaft stundenlang Tickets sortieren, Copilot zuweisen, warten, gucken, nächstes Ticket suchen, wieder zuweisen, wieder warten?

    Das ist natürlich Quatsch.

    Also macht man, was man als fauler Informatiker macht: Man automatisiert den langweiligen Teil.

    So weit, so nett. Aber nach dem ersten erfolgreichen Copilot-PR kommt natürlich sofort die nächste Frage:

    Warum muss ich eigentlich den nächsten Copilot-Lauf wieder selbst anschubsen?

    Und direkt danach kommt die zweite Frage, die meistens etwas mehr nach verbranntem Toast riecht:

    Warum habe ich eigentlich gerade acht Copilot-PRs gleichzeitig, die alle dieselbe Datei anfassen?

    Und damit sind wir beim Perpetuum mobile.

    Die Idee

    Ein echtes Perpetuum mobile funktioniert nicht. Thermodynamik, Physikunterricht, sehr traurige Bastler mit Magneträdern, ihr kennt das.

    Ein Repository kann aber so tun als ob.

    Die Idee ist simpel: Wenn ein Projekt eine halbwegs vernünftige Roadmap hat, dann kann man diese Roadmap in Issues schneiden. Und wenn diese Issues gut genug beschrieben sind, dann kann Copilot sie nacheinander abarbeiten. Und wenn ein Issue fertig ist, kann ein Workflow das nächste Issue aktivieren. Und wenn das fertig ist, das nächste. Und so weiter, bis entweder die Roadmap leer ist oder die Realität wieder eine Produktentscheidung verlangt.

    Das ist kein “KI übernimmt jetzt alles”-Zauber. Das ist eher ein Förderband. Man legt vorne sinnvoll portionierte Arbeit drauf, und hinten kommen Pull Requests raus. Manchmal gute. Manchmal welche, bei denen man dem Agenten freundlich erklärt, dass “funktioniert bei mir” kein Testkonzept ist.

    Der entscheidende Punkt ist dabei das nacheinander.

    Copilot kann parallel arbeiten. GitHub kann parallel Issues zuweisen. Moderne Agenten können mit beeindruckender Geschwindigkeit beeindruckend viele Branches erzeugen. Das klingt erstmal nach Produktivität, ist aber bei echten Projekten sehr schnell nur eine andere Schreibweise für Merge-Konflikte.

    Issue 4 ändert die API. Issue 5 baut schon gegen die alte API. Issue 6 räumt nebenbei Komponenten auf. Issue 7 hat dieselbe Datei “nur kurz” formatiert. Und dann sitzt man da, betrachtet vier Pull Requests, die einzeln plausibel sind, zusammen aber aussehen wie ein Auffahrunfall auf der A3 bei Regen.

    Genau diesen Unsinn will ich nicht.

    Ich will nicht keine Kontrolle. Ich will nur nicht die Art Kontrolle, bei der ich den ganzen Tag Tickets von links nach rechts schiebe, obwohl die Reihenfolge vorher schon in der Roadmap steht.

    Die Zutaten

    Man braucht dafür erstaunlich wenig:

    • eine Roadmap, die nicht nur aus Wunschdenken und Nebel besteht,
    • GitHub Issues mit klaren Akzeptanzkriterien,
    • ein paar Labels,
    • einen Sequencer, der das nächste Issue aktiviert,
    • und optional einen Automerge-Workflow, der nur dann merged, wenn die Welt nicht brennt.

    Die Labels sind dabei die eigentliche Fernbedienung:

    copilot:queued   liegt bereit und darf irgendwann drankommen
copilot:active   ist gerade an der Reihe
agentic-ready    ist klein genug und ordentlich beschrieben
blocked          bitte nicht anfassen, hier fehlt noch Hirn
priority:high    kommt weiter nach vorne

    Das Schöne daran ist, dass es nicht besonders schlau ist. Und das meine ich positiv. Sobald Automatisierung zu schlau sein möchte, entwickelt sie gerne eine Persönlichkeit, die ich in Produktionssystemen nicht haben will.

    Der Sequencer muss nicht “verstehen”, was Produktstrategie ist. Er muss nur respektieren, dass Issue 12 vor Issue 13 kommt, dass blocked wirklich blocked heißt und dass immer nur ein Copilot-Ticket aktiv sein soll. Das ist ungefähr die Menge an Intelligenz, die ich in diesem Teil des Systems haben möchte.

    Das wichtigste Teil: gute Issues

    Der Trick ist nicht der Workflow. Der Trick ist das Issue.

    Ein schlechtes Issue sagt:

    Mach mal Login besser.

    Das ist kein Issue. Das ist ein Hilferuf.

    Ein brauchbares Issue sagt eher:

    ## Ziel
Die Setup-Seite zeigt fehlende Mailbox-Recovery-Konfigurationen an.

## Akzeptanzkriterien
- Fehlende Werte erscheinen als Warnung.
- Die Warnung nennt den konkreten nächsten Schritt.
- Der Health-Endpoint liefert dieselbe Information maschinenlesbar.
- Tests decken fehlende und vorhandene Konfiguration ab.

## Nicht-Ziele
- Keine neue Provider-Integration.
- Keine Änderung an bestehenden Secrets.

    Damit kann ein Agent arbeiten. Da steht drin, was passieren soll, woran man erkennt, dass es fertig ist, und wo er bitte seine Finger rauslassen soll. Letzteres ist wichtig, weil Agenten sonst manchmal den Ehrgeiz eines Praktikanten am dritten Tag entwickeln: “Ich habe nebenbei noch das Auth-System refactored.”

    Danke. Nein.

    Der Sequencer

    Der Sequencer ist ein kleines Script, das regelmäßig schaut, ob gerade ein Issue aktiv ist. Falls nein, sucht es das nächste offene, nicht blockierte Issue mit copilot:queued und macht daraus copilot:active.

    Praktisch bedeutet das: Ich kann eine von ChatGPT vorbereitete Roadmap nehmen, daraus GitHub Issues erzeugen, die Issues einmal sauber priorisieren und dann dem Repository sagen: Hier, arbeite das bitte der Reihe nach ab. Nicht alles auf einmal. Nicht “mal schauen, was passiert”. Sondern schön eins nach dem anderen, wie bei Menschen, nur ohne Stand-up.

    Das kann man sehr schlicht per GitHub Actions laufen lassen:

    name: Copilot Issue Sequencer

on:
  schedule:
    - cron: "17 * * * *"
  workflow_dispatch:

jobs:
  activate-next:
    runs-on: ubuntu-latest
    permissions:
      issues: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "22"
      - run: node scripts/copilot-issue-sequencer.mjs

    Warum nicht alles gleichzeitig aktivieren?

    Weil das dann keine Automation ist, sondern Konfetti mit Schreibrechten.

    Ein aktives Issue nach dem anderen ist langweilig, aber langweilig ist bei Infrastruktur eine unterschätzte Tugend.

    Natürlich ist das langsamer als zehn Agenten gleichzeitig losrennen zu lassen. Aber es ist schneller als zehn Agenten gleichzeitig losrennen zu lassen und danach einen Nachmittag damit zu verbringen, aus fünf halb überlappenden PRs wieder eine lineare Geschichte zu basteln.

    Automerge, aber nicht lebensmüde

    Der zweite Teil ist Automerge. Auch hier gilt: Man kann das vernünftig machen oder man kann sich später wundern.

    Meine Mindestregeln wären:

    • nur Copilot-PRs oder explizit markierte PRs,
    • keine Drafts,
    • alle Pflichtchecks grün,
    • keine blockierten Issues,
    • riskante Bereiche brauchen weiter menschliches Review.

    Damit ist Automerge nicht “Augen zu und durch”, sondern eher: Wenn alles, was wir vorher als wichtig definiert haben, grün ist, dann bitte nicht noch drei Tage auf einen Klick warten.

    Und genau hier schließt sich der Kreis: Wenn ein PR sauber merged, kann der nächste Lauf starten. Nicht, weil irgendein Mensch gerade zufällig vor GitHub sitzt, sondern weil das Projekt selbst weiß: Dieses Stück ist erledigt, jetzt kommt das nächste.

    Roadmap schneiden

    Der Teil, der gerne unterschätzt wird: Man muss die Roadmap vorher ehrlich machen.

    “Wir bauen eine großartige Plattform” ist keine Roadmap. “Wir bauen zuerst Import/Export, dann persistente Sessions, dann ein Rechtekonzept, dann Auswertungen” ist schon besser. “Issue 12 baut den Storage-Adapter, Issue 13 hängt Quiz-Inhalte daran, Issue 14 exportiert Ergebnisse als CSV und JSON” ist agententauglich.

    Das ist übrigens auch der Moment, an dem ChatGPT wieder sehr nützlich ist. Nicht als Orakel, sondern als Roadmap-Zerlegehilfe. Man kann sagen: Hier ist das Projekt, hier sind die Ziele, mach daraus bitte Arbeitspakete, die ein Agent in einem überschaubaren Pull Request erledigen kann. Danach muss man trotzdem noch drüberschauen. Aber das ist eine andere Art Arbeit als stumpfes Ticket-Schubsen.

    Man merkt dabei auch sehr schnell, welche Dinge noch nicht reif sind. Und das ist gut. Dann kommt blocked drauf. Nicht als Schande, sondern als kleines gelbes Warnschild: Hier bitte erst denken, dann Agent.

    Fazit

    Am Ende ist das Ganze weniger Science-Fiction, als es klingt. Es ist ein Issue-Stapel mit Anstand, ein kleines Script, ein paar Labels und die Bereitschaft, Arbeit so zu beschreiben, dass nicht nur ein Mensch mit viel Kontext sie versteht.

    Für jemanden wie mich ist das ziemlich nah an idealer Faulheit: Ich muss immer noch denken, aber ich muss nicht mehr jeden Kleinkram selbst heruntertippen. Ich muss immer noch kontrollieren, aber ich muss nicht mehr jedes Ticket einzeln anschieben. Ich muss immer noch wissen, was ich will, aber ich darf den langweiligen Teil häufiger an Maschinen delegieren.

    Und wenn Copilot dann einen PR baut, der merged, woraufhin der Workflow das nächste Issue aktiviert, woraufhin Copilot wieder losläuft, dann ist das natürlich kein echtes Perpetuum mobile.

    Aber es fühlt sich kurz so an.

    Und für einen faulen Informatiker ist das schon ziemlich nah dran.

  • Wie man gute Pubquizfragen baut – oder: Im Zweifel Kanada

    Wie man gute Pubquizfragen baut – oder: Im Zweifel Kanada

    Ein gutes Pubquiz zu bauen ist deutlich schwieriger, als es auf den ersten Blick aussieht.

    Das klingt erstmal komisch, weil Fragen stellen ja nun wirklich jeder kann. “Was ist die Hauptstadt von Frankreich?”, “Wer sang Bohemian Rhapsody?”, “Wie viele Beine hat eine Spinne?” und fertig ist die Laube.

    Nun.

    Leider nein.

    Ein Pubquiz ist kein Einstellungstest, keine Abiturprüfung, kein Kneipen-Trivial-Pursuit und auch kein Versuch, den Raum davon zu überzeugen, dass man selbst im Wikipedia-Kaninchenbau besonders tief graben kann. Ein gutes Pubquiz ist im Idealfall ein Abend, an dem sehr unterschiedliche Menschen gemeinsam rätseln, diskutieren, sich kurz sicher sind, dann wieder unsicher werden, am Ende doch die erste Idee nehmen und anschließend entweder triumphieren oder leise fluchen.

    Und genau da wird es schwierig.

    Denn ein Quiz muss balanciert sein.

    Bei einem Quiz mit 50 Punkten sollte genug Diversifizierung drin sein, damit nicht nach Runde zwei klar ist, welches Team gewinnt. Es braucht Popkultur, Geschichte, Geographie, Musik, Sport, Wissenschaft, Alltag, vielleicht ein bisschen Lokalkolorit und idealerweise ein paar Fragen, bei denen man nicht einfach Wissen abruft, sondern gemeinsam herleitet.

    Gleichzeitig darf man Einsteiger nicht direkt verlieren.

    Wenn die ersten fünf Fragen so gebaut sind, dass nur Menschen mit einem Nebenfach in byzantinischer Münzprägung überhaupt eine Chance haben, dann ist das vielleicht intellektuell befriedigend für den Fragenersteller, aber kein guter Abend für den Raum.

    Die Kunst liegt darin, Fragen zu bauen, bei denen Teams zumindest das Gefühl haben, sie könnten drauf kommen.

    Das ist ein großer Unterschied.

    Eine gute Frage ist nicht zwingend leicht. Eine gute Frage gibt aber Anknüpfungspunkte. Man erkennt vielleicht ein Jahrzehnt, ein Land, eine Wortherkunft, eine Melodie, einen Schauspieler, ein Logo, einen Zusammenhang. Dann beginnt dieses schöne Pubquiz-Gemurmel am Tisch:

    “Warte, das war doch Kanada, oder?”
    “Nein, Kanada war das andere.”
    “Bist Du sicher?”
    “Nein.”
    “Dann nehmen wir Kanada.”

    Und manchmal ist das sogar richtig.

    Im Zweifel ist die Antwort nämlich Kanada.

    Nicht immer natürlich. Aber erstaunlich oft genug, dass man daraus eine Regel machen möchte.

    Was man bei Quizfragen vermeiden sollte: reine Binär-Abfragen ohne Spaß. “In welchem Jahr wurde exakt X gegründet?” ist meistens keine gute Frage, wenn das Jahr nicht irgendwie herleitbar oder kulturell verankert ist. 1871? 1949? 1969? Alles kann alles sein. Das ist dann kein Rätseln, sondern Datums-Lotto.

    Besser ist: eine Frage so bauen, dass die Antwort zwar konkret ist, der Weg dahin aber über gemeinsames Denken führt.

    Also nicht:

    “In welchem Jahr wurde Kanada gegründet?”

    Sondern eher:

    “Welches heutige G7-Land entstand 1867 durch den British North America Act als Dominion?”

    Das ist immer noch nicht geschenkt. Aber es hat Haken. G7. British. North America. Dominion. Man kann arbeiten.

    Ein anderes Problem: Fragen, die nur für eine bestimmte Altersgruppe funktionieren. Wenn jede Musikfrage aus den 90ern kommt, freuen sich Menschen meines Alters, aber der Rest schaut irgendwann so, wie ich schaue, wenn jemand aktuelle TikTok-Sounds abfragt. Umgekehrt funktioniert es natürlich genauso.

    Ein gutes Quiz braucht daher Streuung.

    Nicht nur thematisch, sondern auch generationell. Eine 20-jährige Person sollte Punkte holen können. Eine 50-jährige Person auch. Das Team mit Sportnerd soll einen Moment haben, das Team mit Literaturmensch ebenfalls. Und irgendwo muss es eine Frage geben, bei der alle am Tisch “ach komm, das weiß doch jeder” sagen und dann drei verschiedene Antworten aufschreiben.

    Wichtig ist auch die Dramaturgie.

    Man sollte nicht mit den härtesten Fragen starten. Die ersten Punkte müssen einladend sein. Teams sollen reinkommen, sich sortieren, erste Erfolgserlebnisse haben. Danach darf es schwerer werden. Ein Quizabend verträgt ein paar richtige Brecher, aber nicht 50 davon.

    Ich mag Fragen, die auf den ersten Blick leicht wirken und dann eine kleine Drehung haben. Oder solche, bei denen die intuitive Antwort tatsächlich die richtige ist.

    Das ist überhaupt eine der schönsten Pubquiz-Beobachtungen: Die erste Antwort ist oft die beste.

    Nicht immer. Aber oft.

    Teams reden sich regelmäßig aus richtigen Antworten heraus. Da steht nach zehn Sekunden das Richtige auf dem Zettel, dann kommen Zweifel, dann kommt jemand mit gefährlichem Halbwissen, dann wird umgeschrieben, und am Ende ist es falsch.

    Das gehört dazu. Das ist sogar Teil des Spiels.

    Ein guter Quizmaster baut Fragen so, dass dieser Moment entstehen kann, ohne unfair zu sein. Nicht durch Trickserei, nicht durch “haha, reingelegt”, sondern durch saubere Formulierung und plausible Distraktoren im Kopf der Teams.

    Am Ende ist ein gutes Pubquiz kein Wissenstest, sondern ein sozialer Mechanismus mit Bierbegleitung.

    Es muss genug einfache Punkte geben, damit neue Teams wiederkommen.

    Es muss genug schwere Punkte geben, damit gute Teams sich anstrengen müssen.

    Es muss genug Vielfalt geben, damit niemand den ganzen Abend nur Deko ist.

    Und es muss mindestens eine Frage geben, bei der man später sagt:

    “Verdammt. Ich wollte Kanada nehmen.”

    Heiter weiter!

    C.

  • It’s been a while. Again.

    Latest News Subscribe Update

    Nach gefühlten drölf Jahren gibt es mal wieder neuen Content auf diesem Internettagebuch.

    Warum?

    Nun.

    Unter anderem, weil der Küchenserver noch da ist. Was an sich schon bemerkenswert ist, denn Dinge im Internet haben ja inzwischen oft eine Halbwertszeit irgendwo zwischen “Startup wurde acqui-hired” und “wir haben unsere API leider eingestellt”.

    Dieses Blog hingegen steht noch. Es hat Umzüge, PHP-Versionen, WordPress-Updates, kaputte Plugins, Themewechsel und diverse Phasen meines Lebens überlebt. Also eigentlich alles, was man einem privaten Blog so zumuten kann.

    Und vielleicht ist genau das gerade wieder charmant.

    Nicht jeder Gedanke muss in eine Timeline, nicht jede Beobachtung braucht einen Algorithmus, nicht jeder kleine technische Fund muss in irgendeinem Slack verschwinden, wo ihn drei Tage später niemand mehr findet. Manchmal reicht auch ein Blogpost. Eine URL. Ein Datum. Fertig.

    Ob das hier jetzt wieder regelmäßig passiert?

    Keine Ahnung.

    Ich nehme mir ausdrücklich nicht vor, ab jetzt wieder wöchentlich zu bloggen, weil solche Vorsätze ungefähr so zuverlässig sind wie Drucker unter Windows, Faxsoftware im Jahr 2020 oder “nur mal eben” ein Docker-Compose-File anzupassen.

    Aber ein paar Dinge gäbe es schon aufzuschreiben.

    Über Technik, die still funktionieren darf. Über Selfhosting und die Frage, ab wann Hobby in Infrastruktur übergeht. Über Backups, bei denen Restore der einzige Teil ist, der zählt. Über Reisen, Hamburg, Alltag, Automatisierung, vielleicht auch darüber, warum gute Pubquizfragen schwieriger sind als schlechte Architekturdiagramme.

    Also: mal sehen.

    Der Küchenserver steht noch.

    Heiter weiter!

    C.

  • Hello Fresh – Test der Kochbox

    Hello Fresh – Test der Kochbox

    Wie Einige von Euch ja bereits auf Knitterfees Blog gesehen haben, testen wir gerade bei uns zu Hause unterschiedliche Kochboxen. Das Konzept dahinter ist so einfach wie genial: Es wird eine Art Bausatz für zwei bis fünf Mahlzeiten wird wöchentlich nach Hause geliefert. Die Boxen beinhalten dann neben den Rezepten, die idiotensicher sein sollten, auch alle benötigten Zutaten. Dazu sollten sie zwei Erwachsene satt machen und einige Herstelller – darunter Hello Fresh – werben damit, überwiegend Bioprodukte zu verarbeiten. Alles in allem also viele erstrebenswerte Dinge, vor allem, da ich 39 EUR für drei Mahlzeiten oder 49 EUR für vier Mahlzeiten nicht überteuert finde.

    Wir haben letzte Woche Kochzauber getestet, da lief alles glatt, aber wir waren irgendwie nicht so ganz überzeugt; warum, kann ich im Nachhinein gar nicht mehr sagen. Die Rezepte stimmten, alle Zutaten wurden mitgeliefert, wir sind satt geworden und es gab interessante Gerichte. Und das Beste daran: die Rezepte waren so gut, dass ich keins davon versaubeutelt hab.

    Diese Woche ist Hello Fresh dran. Wir testen zwar noch, aber ich bereue es nicht, bereits nach dem ersten Rezept die Box wieder abbestellt zu haben. Ich versuche, die Gründe, die sich teilweise auch erst nach und nach im Laufe der Woche ergeben haben, zusammenzufassen:

    • HelloFresh macht nicht sattLeider wurden wir gerade bei den Gerichten mit Fleischanteil nicht satt. 200g Putenbrust für zwei Personen ist einfach sehr, sehr wenig – und auch wenn HelloFresh es behauptet, satt kann man davon einfach nicht werden. Bei Biofleisch hätte ich die geringere Menge akzeptiert, auch sofern eine Kompensation durch mehr Gemüse gegeben wäre, aber auch das gibt’s hier nicht. Für mich scheint das eine recht einfache Maßnahme zur Gewinnmaximierung zu sein; bei Gerichten mit nicht so teuren Zutaten – der Kürbissuppe – reichen die Portionen nämlich locker zum satt werden aus.
    • HelloFresh ist nicht zu 80% BioIch kann nicht glauben, dass HelloFresh zu 80% Bio Zutaten verarbeitet. Gut, es waren in unserer Lieferung  zwar viele der abgepackten Produkte Bio, das Fleisch war jedoch nicht bio und auch das Gemüse und die Gewürze hatten keine Bio-Kennzeichnung, genauso wie die Nudeln und der Reis. Da HelloFresh jedoch leider keine Auflistung darüber bereitstellt, welche Zutaten wie zertifiziert sind, muss ich damit davon ausgehen, dass der überwiegende Teil der Produkte nicht bio ist. Und das ist mir gerade bei Gemüse und Fleisch wichtig; ob der Apfelsaft nun demeter ist oder nicht, das ist für mich nicht so relevant.
    • HelloFresh prüft die Rezepte nichtIn unserer Box gab es bislang in jedem Rezept einen Fehler oder eine Unverständlichkeit. So fehlten in den Rezepten teilweise Zutaten (Orangensaft und Paprikapulver – wann gibt man diese zu?), die in den Zutatenlisten zu den einzelnen Gerichten aufgelistet waren, es wird verlangt aus 200g Hack + Ei + Semmelbröseln und einer halben Zwiebel 15 Hackbällchen zu formen (das Rezept ist gleich geschrieben für 2, 4 und 6 Personen), teilweise stimmen Namen auf den Zutaten und in den Rezepten nicht überein (geriebene Chillies vs. Cayennepfeffer) oder werden Zutaten mitgeliefert, die weder in der Zutatenliste noch im Rezept erwähnt sind (Kürbiskerne wurden mitgeliefert, obwohl eigentlich vorgesehen war, die Kerne des Kürbis selbst zu rösten).
      Für mich wirkt das so, als würden die Rezepte nicht ausprobiert, bevor die Box verschickt wird. Anders kann ich mir diese Häufigkeit an Fehlern nicht erklären.
    • HelloFresh liefert fehlerhaftIn unserer Box wurde die dreifache Menge Cayennepfeffer (3g statt 1g) geliefert; wenn ich das nicht vorher gemerkt hätte, hätte das ein ganzes Gericht ordentlich verhauen können. Außerdem fehlen die Semmelbrösel, die in der Zutatenliste aufgeführt, aber nicht mitgeliefert wurden.
    • HelloFresh macht unrealistische Annahmen an KüchenausstattungIn einem der aktuellen Rezepte (Kürbissuppe) wird nebenbei gefordert, die Suppe mit einem Stabmixer zu pürieren. Wir hatten Glück und einen ebensolchen Stabmixer durch Zufall im Haus; zur normalen Küchenausstattung gehört sowas aber nicht. Ebenfalls nicht gut: HelloFresh hat keine Übersicht am Anfang eines Rezepts oder für die gesamte Woche, welche Küchenutensilien verwendet werden. Vielleicht kann man ja einen Stabmixer kaufen oder ausborgen, wenn man vorher weiß, dass er benötigt wird. Wenn er jedoch in der Mitte des Rezepts in einem Nebensatz auftaucht, ist das mehr als unglücklich.
    • HelloFresh ist langweiligDie Gerichte, die HelloFresh auf den Tisch bringt, sind allesamt so oder sehr ähnlich bei uns zu Hause schon einmal gekocht worden: Hackbällchen aus dem Ofen in Tomatensauce auf Reis, Geflügelbrust in Sahnesauce auf Penne, Kürbissuppe. Ich habe mir hier mehr Abwechslung oder gewagtere Gerichte erhofft, Zutaten, die man sonst nicht verarbeitet. Massenkompatiblität geht hier offenbar vor.
    • HelloFresh ist intransparentHelloFresh ist eine Rocket Internet Tochter. Das steht aber nicht im Impressum, sondern lediglich in den Stellenanzeigen. Es gibt – im Gegensatz zu z.B. der UK Webseite des Franchise – keine Fotos des Teams, nur hier und da werden sporadisch Namen genannt. Zutaten und Mengen kann man vorab nicht sehen, Lieferanten werden nicht genannt. Im Gegensatz dazu, auch auf der UK Website, sieht man genau die gelieferten Mengen für die Rezepte dokumentiert: http://checkthis.com/qq9h und bekommt ebenfalls die Lieferanten namentlich genannt: http://www.hellofresh.co.uk/aboutus_ingredients/. All das gibt es auf der deutschen Website nicht, stattdessen Allgemeinplätze über gesundes Essen und 100 andere Gründe, warum die Idee, die 5 andere Anbieter in Deutschland ebenfalls am Markt haben, im Prinzip eine gute ist. Keine Differentiatoren (wir sind besser, schöner, schneller, toller, netter weil…), keine Unternehmensgeschichte.
    • HelloFresh baut auf PraktikantenWenn wir uns das aktuelle Jobs-Seite von HelloFresh anschauen, fällt auf, dass 50% der zu besetzenden Stellen Praktikatenjobs sind. http://www.hellofresh.de/jobs/
      Für mich sieht es so aus, als hätte Rocket Internet die Idee oder Brand HelloFresh lizenisert und versucht jetzt das Ganze gewinnmaximiert und ohne Herzblut in den deutschen Markt zu bringen. Hier gibt es keine “Nasen”, die das Produkt entwickelt haben, keine Gründer, die eine Geschichte zu erzählen haben; stattdessen potentiell schlecht bezahlte Praktikanten ohne Erfahrung und ohne persönlichen Bezug zum Produkt. Es ist nunmal ein Unterschied, ob man selbst Gründer eines Startup ist oder nur ein Praktikum bei irgendeiner Web 2.0 Bude macht – und das hat potentiell auch Auswirkungen auf die Arbeit, die abgeliefert wird. Das würde zum Beispiel die fehlerhaften Rezepte, die fehlerhaft gepackte Box, aber auch so Dinge wie den grammatikalisch, orthographisch und stilistisch nicht mal mehr grenzwertig  geschriebenen Affiliate-Partner-Guide erklären. You get what you pay for.

    Fazit für mich: Ich bin froh, wenn nächste Woche wieder ein anderer Anbieter auf den Tisch kommt und werde mir 3x überlegen, ob ich bei HelloFresh in der Zukunft Geschäft generieren werde. Es gibt einfach bessere Alternativen zu deren Produkt am Markt. Desweiteren vermute ich, dass die HelloFresh Erfahrung auch Auswirkungen auf mein Konsumverhalten bei anderen Rocket Internet Unternehmen haben wird.