Nicht auf das Feature warten — die App selbst ändern

Das Überraschende ist nicht, dass ein Telegram-Fork einen Digest-Tab bekam. Entscheidend ist, dass ich dafür keinen Android-Buildplan schreiben musste. Ich beschrieb das fehlende Verhalten in Alltagssprache, schloss das Smartphone an und schrieb später nur: „Starte die neueste Version auf meinem Smartphone.“ Noch am selben Abend nutzte ich meinen eigenen Build.

Am Morgen gab es diese Funktion noch nicht

Abonnierte Kanäle enden meist in einem von zwei gleichermaßen unbefriedigenden Zuständen: Hunderte roter Zähler sind sichtbar, oder alles wird als gelesen markiert und nützliche Beiträge verschwinden. Ich wollte ein drittes Modell: selbst eine Handvoll Kanäle auswählen und anschließend alle ungelesenen Beiträge in einer einzigen normalen Zeitleiste lesen.

Der daraus entstandene Tab Digest tut genau das:

• Er lässt Kanäle durchsuchen und führt ihre Beiträge chronologisch zusammen.
• Er speichert für jedes Konto eine eigene Zuletzt-gelesen-Marke.
• Er öffnet beim ersten ungelesenen Element und scrollt unbegrenzt in die Vergangenheit.
• Er zeigt Kanalnamen, Medienalben, Daten und Reaktionen mit Telegrams eigener Oberfläche.
• Er markiert sichtbare Nachrichten über denselben Weg als gelesen wie ein normaler Kanal.

Das ist weder eine kleine Demo noch ein von Grund auf neu gezeichneter Client. Der Agent musste die Basis auf den neuesten veröffentlichten Telegram-Quellstand bringen und dessen lokale Datenbank, Paginierung, Mediengruppierung und Navigation verstehen. Ich musste ihm aber keine Klassennamen diktieren. Ich beschrieb, was der Mensch bei der Benutzung sehen und erleben sollte.

Die Arbeit war Engineering. Der Prompt war Alltagssprache

Die zentrale Anweisung sah ungefähr so aus. Der letzte Satz war wichtig: Er hinderte den Agenten daran, neben Telegrams bestehender Oberfläche eine zweite, sichtbar fremde Benutzeroberfläche zu bauen.

Füge eine eigene Seite mit allen ungelesenen Nachrichten aus den von mir ausgewählten Telegram-Kanälen hinzu.

Ich brauche eine Kanalauswahl. Führe für Digest eine eigene Marke für das letzte Element, das ich tatsächlich gelesen habe. Positioniere die Seite beim Öffnen auf der ersten ungelesenen Nachricht. Füge unendliches Scrollen in die Vergangenheit und unten einen Button hinzu, der zum ersten ungelesenen Element zurückführt. Markiere sichtbare Beiträge über Telegrams normalen Lesestatus als gelesen.

Stelle Alben, Kanalname und Avatar genauso dar, wie Telegram es normalerweise tut. Verwende die bestehende Oberfläche so weit wie möglich; schreibe nur dort eigene UI, wo es unvermeidbar ist.

Baue die App, installiere sie auf dem angeschlossenen Smartphone und überprüfe das Ergebnis auf dem Gerät.

Ein paar Stunden später lief die App auf einem Redmi Note 8 Pro. Danach gab ich zwei kurze Folgeanweisungen: das Ruckeln beim Scrollen beseitigen sowie den runden Button über die untere Navigation verschieben und dabei einen verirrten Avatar zwischen den Nachrichten entfernen. Claude untersuchte das Ergebnis auf dem Smartphone, fand die Ursachen, baute die APK neu und prüfte erneut. Es fühlte sich eher nach Zusammenarbeit mit einem Produktteam an als nach „Codegenerierung“.

Code wird billiger; präzise Absichten werden wertvoller

Früher lag eine teure Kette zwischen „Ich brauche das“ und „Ich benutze es“: einen Android-Entwickler finden, die Architektur erklären, die Umgebung zusammenstellen, auf Builds warten und ADB lernen. Das hat uns daran gewöhnt, die Oberfläche einer App als endgültig zu betrachten. Wir akzeptieren, was der Anbieter liefert, und warten auf die nächste Version.

Ein Coding-Agent verändert die Wirtschaftlichkeit dieser Kette. Er kann ein großes, unbekanntes Repository lesen, JDK-, SDK- und NDK-Versionen aufeinander abstimmen, den richtigen Integrationspunkt finden, eine APK bauen, einen Installationsfehler untersuchen, logcat lesen und den Vorgang wiederholen. Nicht jedes Ergebnis ist gut, aber die Kosten für eine erste funktionierende Version sind drastisch gesunken.

Das gilt nicht für alles. Eine geschlossene App ohne Quellcode, eine serverseitige Funktion, Zahlungsinfrastruktur oder eine Änderung an einem kryptografischen Protokoll entstehen nicht durch einen einzigen Prompt. Doch wenn das gewünschte Verhalten in einem offenen Android-Client steckt und auf dem Bildschirm überprüft werden kann, ist es nicht mehr immer vernünftig, auf den offiziellen Button zu warten.

So lässt es sich wiederholen: Nur die nötigen Schritte bleiben beim Menschen

Der folgende Ablauf ist auf diesen Fork zugeschnitten. Sie brauchen einen Computer, einen terminalfähigen Coding-Agenten wie Claude Code oder Codex, ein Android-Smartphone, ein USB-Datenkabel und mehrere Gigabyte freien Speicherplatz. Das Repository ist groß und der erste Android-Build braucht Zeit. Lassen Sie den Agenten die technische Umgebung vorbereiten; Sie tragen private Zugangsdaten ein, ändern die Telefoneinstellungen und melden sich bei Telegram an.

1 Den Agenten das Projekt vorbereiten lassen

Öffnen Sie den Agenten in einem leeren Ordner. Das ursprüngliche Projekt begann mit einer ebenso kurzen Anfrage: den offiziellen Android-Client forken und auf dem verbundenen Smartphone starten. Für den fertigen öffentlichen Fork verwenden Sie:

Klone https://github.com/howaihelps/tg-digest-android und starte die neueste Version auf meinem per USB verbundenen Android-Smartphone.

Sag mir, wann ich meine eigene Telegram app id und meinen app hash eingeben oder etwas auf dem Smartphone bestätigen muss. Zeige und committe diese Zugangsdaten nicht.

2 Eigene Telegram API ID und eigenen Hash beziehen

Das ist kein Bot-Token. Telegram vergibt ein Wertepaar pro Telefonnummer und verlangt für einen Drittanbieter-Client eine persönliche ID. Siehe Telegrams offizielle Anleitung.

Öffnen Sie im Stammverzeichnis des geklonten Repositorys, neben settings.gradle, die Datei local.properties und ersetzen Sie die Platzhalter manuell. Verwenden Sie keine Anführungszeichen:

sdk.dir=/Users/[IHR_NAME]/Library/Android/sdk
TELEGRAM_API_ID=[IHRE_NUMERISCHE_API_ID]
TELEGRAM_API_HASH=[IHR_API_HASH_MIT_32_ZEICHEN]

Der Pfad sdk.dir unterscheidet sich unter Windows und Linux; der Agent sollte ihn bereits eingetragen haben. In diesem Fork übernimmt TMessagesProj/build.gradle die beiden Werte in BuildConfig, und BuildVars.java liest sie zur Laufzeit. local.properties steht in .gitignore.

Zum Zeitpunkt der Veröffentlichung hatte ich außerdem meine echten Werte mit jeder Datei in beiden öffentlichen Commits verglichen: Meine persönliche api_id und mein api_hash befanden sich weder im damals veröffentlichten Baum noch im Git-Verlauf. Der importierte Upstream-Quellcode enthält Telegrams standardmäßiges, eingeschränktes Beispielpaar. Das sind nicht meine Zugangsdaten, und Sie dürfen sich für Ihren Build nicht darauf verlassen.

3 Das Smartphone vorbereiten

Die Menünamen unterscheiden sich je nach Hersteller. Die grundlegende Abfolge ist in der offiziellen Android-Anleitung zu den Entwickleroptionen dokumentiert. Lassen Sie den Bildschirm während der ersten Installation entsperrt: Ein Agent kann keinen Systemdialog für Sie bestätigen.

4 Den Agenten bauen und starten lassen

Sobald local.properties vollständig und das Smartphone angeschlossen ist, müssen Sie weder ADB noch Gradle-Task, ABI, CMake, APK-Pfad oder Android-Activity nennen. In der echten Claude-Session bestand meine gesamte Startanfrage aus einem Satz:

Starte die neueste Version auf meinem Smartphone.

Claude prüfte das angeschlossene Gerät selbst, stimmte die Android-Toolchain ab, baute die richtige Variante, installierte und startete sie und untersuchte danach Screenshots. Das waren Handlungen des Agenten, kein verstecktes technisches Wissen in meinem Prompt. Das Ergebnis war eine etwa 75 MB große Debug-APK als org.telegram.messenger.beta auf arm64-v8a. Anmeldecode und Zwei-Faktor-Passwort geben Sie weiterhin selbst ein und niemals an den Agenten weiter.

5 Die eigene Funktion als Ergebnis beschreiben

Nachdem die App gestartet ist, können Sie diesen Fork verändern oder den Ablauf mit einer anderen Open-Source-App wiederholen. Beginnen Sie nicht mit „Erstelle eine Klasse“ oder „Repariere den RecyclerView“. Beschreiben Sie die Situation, das beobachtbare Verhalten und die Abnahmekriterien.

Ändere die App für diesen persönlichen Ablauf.

Derzeit: [Was fehlt oder was ich manuell erledige].
Ich möchte: [Was ich sehen soll und was geschehen soll].
Behalte bei: [Vorhandene Bildschirme und Verhaltensweisen, die unverändert bleiben müssen].

Verwende die vorhandene Oberfläche so weit wie möglich. Setze es um, starte die neueste Version auf meinem verbundenen Smartphone und prüfe das Ergebnis selbst.

6 Das Nutzungserlebnis debuggen, nicht nur den Build

Der erste Digest-Build funktionierte, doch der Feed zuckte leicht, wenn weitere Elemente geladen wurden. Der nächste Prompt enthielt weder Diagnose noch Testplan, sondern nur das, was ich auf dem Smartphone sehen konnte:

Alles funktioniert sehr gut, aber der Bildschirm zuckt beim Scrollen etwas. Kannst du das selbst prüfen und beheben?

Der Agent fand heraus, dass während der Paginierung die gesamte Liste aktualisiert wurde, und ersetzte dies durch ein inkrementelles Update. Bei der wiederholten Messung sank der Anteil ruckelnder Frames von 11,9 % auf 2,1 %, während die Frame-Zeit im 99. Perzentil von 40 auf 22 ms fiel. Einen weiteren visuellen Fehler beschrieb ich noch einfacher: „Verschiebe den Button über die untere Navigation und entferne das Artefakt in der Mitte, aber behalte den Kanalnamen bei.“ Auch das war Alltagssprache, keine UI-Spezifikation. Der abschließende Kompromiss ist eine reine Namenszeile: Der Absender-Avatar, der das Artefakt auslöste, wird nicht dargestellt. Diese Schleife — hinschauen, den Fehler benennen, den Agenten ihn reproduzieren lassen und danach prüfen — ist wichtiger als ein perfekter erster Prompt.

Vor der Veröffentlichung einen eigenen Sicherheits-Prompt verwenden

Eine funktionierende APK macht ein Repository noch nicht sicher. In meiner echten Veröffentlichungsanfrage formulierte ich die Grenze in Alltagssprache; Claude machte daraus vor dem Push Prüfungen der verfolgten Dateien und des Verlaufs:

Pushe alle Änderungen mit einem einzigen guten englischen Commit in das öffentliche Repository.

Pushe unter keinen Umständen meine app id oder meinen app hash. Sie müssen in einer lokalen Datei bleiben, die nicht ins Repository gelangt. Prüfe das vor dem Push sorgfältig.

Telegram für Android wird unter GNU GPL v2 oder neuer verbreitet; deshalb behält der Fork die Lizenz bei und stellt den Quellcode bereit. Hinzu kommt eine praktische Verpflichtung: Pflegen Sie Ihren Fork, prüfen Sie dessen Diff und halten Sie generierten Code nicht automatisch für vertrauenswürdig. Ein Agent senkt die Implementierungskosten drastisch; er nimmt dem Eigentümer nicht die Verantwortung ab.

Keine App für alle — eine App genau für Sie

Ein Massenprodukt muss Funktionen auswählen, die für Millionen Menschen sinnvoll sind. Ein persönlicher Build darf ungewöhnlich, eng umrissen und für eine einzige Person perfekt sein. Hier verändern Agenten Software am stärksten: Sie müssen weder ein Start-up gründen noch jahrelang auf die Abstimmung über einen Feature Request warten. Manchmal reichen ein offenes Repository, eine präzise Beschreibung, ein USB-Kabel und die Bereitschaft, das Ergebnis zu prüfen.

Code ist nicht nutzlos geworden. Er ist sehr viel weniger knapp geworden. Das Recht, ihn zu übernehmen, zu verändern und auf dem eigenen Gerät auszuführen, ist entsprechend wertvoller geworden.

Auf Telegram teilen