Nicht auf das Feature warten — die App selbst ändern

Ich wollte Telegram öffnen und einen einzigen Feed mit ungelesenen Beiträgen sehen — ausschließlich aus den Kanälen, die ich selbst ausgewählt hatte. Diesen Button gab es nicht. Ich stellte keinen Feature Request und wartete darauf, ob er irgendwann auf der Roadmap eines anderen landen würde. Ich öffnete den Quellcode des offiziellen Android-Clients, beschrieb Claude das gewünschte Verhalten, schloss mein Smartphone an und nutzte noch am selben Abend 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.

Der Prompt beschrieb das Verhalten, nicht den Code

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 und fügen Sie den folgenden Prompt ein. Er hält bewusst vor den geheimen Werten an und verweigert das Entfernen einer installierten App, falls Android einen Signaturkonflikt meldet.

Bereite https://github.com/howaihelps/tg-digest-android für einen lokalen Build vor.

Arbeite selbstständig: Klone das Projekt, lies die README und untersuche den Git-Verlauf sowie den Arbeitsbaum. Ermittle mein Betriebssystem und prüfe Git, JDK 17, Android SDK / Build Tools 35, NDK 27.2.12479018, CMake und platform-tools. Bereite alles Fehlende vor; wenn ein Download oder eine Installation meine Erlaubnis braucht, frage einmal danach und erkläre genau, warum.

Gib TELEGRAM_API_ID oder TELEGRAM_API_HASH niemals aus, übertrage sie nicht und committe sie nicht. Prüfe, ob local.properties im Stammverzeichnis von Git ignoriert wird. Falls die Datei nicht existiert, erstelle eine sichere Vorlage, die nur den korrekten sdk.dir und Platzhalter für die beiden Werte enthält. Halte dann an und bitte mich, sie manuell einzutragen.

Baue und pushe noch nichts. Berichte abschließend nur den Pfad des Repositorys, die Einsatzbereitschaft der Toolchain, den Pfad zu local.properties und meinen nächsten Schritt.

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, senden Sie den nächsten Prompt. Das ist die Startanweisung. Die erwarteten README-Befehle sind enthalten, aber Sie müssen sie weder verstehen noch selbst ausführen.

Die Zugangsdaten in local.properties sind eingetragen, und das entsperrte Android-Smartphone ist über USB angeschlossen. Baue die App und führe sie darauf aus.

Arbeite weiter, bis ein überprüfbares Ergebnis vorliegt. Gib TELEGRAM_API_ID oder TELEGRAM_API_HASH nicht aus, und prüfe vor jeder Git-Aktion, dass local.properties nicht verfolgt wird.

1. Führe adb devices -l aus. Wenn der Status unauthorized lautet, bitte mich, den RSA-Dialog zu bestätigen, und fahre dann fort.
2. Prüfe die ABI mit adb shell getprop ro.product.cpu.abilist. Dieser Fork wird derzeit nur für arm64-v8a gebaut. Falls das Smartphone arm64-v8a nicht unterstützt, passe die ABI-Konfiguration mit der kleinstmöglichen Änderung an und erkläre sie.
3. Bereite PATH, JAVA_HOME, ANDROID_HOME und ANDROID_SDK_ROOT vor; stimme die installierte CMake-Version mit Gradle ab.
4. Führe ./gradlew :TMessagesProj_App:assembleAfatDebug aus. Behebe Umgebungs- oder Buildfehler, statt nach dem ersten Fehler anzuhalten.
5. Erwartete APK: TMessagesProj_App/build/outputs/apk/afat/debug/app.apk. Installiere sie mit adb install -r.
6. Falls die Installation blockiert wird, bitte mich, Über USB installieren zu aktivieren. Wenn Android einen Signaturkonflikt meldet, deinstalliere die alte App NICHT ohne meine ausdrückliche Erlaubnis: Eine Deinstallation löscht ihre lokalen Daten.
7. Starte das Package org.telegram.messenger.beta und prüfe, ob der erste Bildschirm geöffnet wird und der Digest-Tab vorhanden ist. Nutze adb, logcat und Screenshots zur Diagnose.

Berichte abschließend den Pfad und die Größe der APK, die Geräte-ABI, das Installationsergebnis, das gestartete Package/die gestartete Activity und was ich visuell prüfen soll. Pushe nichts.

Die aktuelle Konfiguration wurde auf arm64-v8a überprüft: Eine Debug-APK von ungefähr 75 MB wurde gebaut, installiert und als org.telegram.messenger.beta gestartet. Beim ersten Start müssen Sie sich noch selbst bei Telegram anmelden und den Anmeldecode sowie gegebenenfalls das Passwort für die Zwei-Faktor-Authentifizierung eingeben. Geben Sie diese Daten nicht 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, die auf meinem Smartphone läuft, für diesen persönlichen Arbeitsablauf.

Problem: [Was ich derzeit manuell erledige oder was fehlt].
Gewünschtes Verhalten: [Was ich sehen soll und was nach jeder Aktion geschehen soll].
Daten und Zustand: [Was gespeichert werden soll, wann es aktualisiert wird und was einen Neustart überstehen muss].
Grenzen: [Was sich nicht ändern darf; welche nativen Bildschirme und Verhaltensweisen erhalten bleiben müssen].
Fertig, wenn:
- [überprüfbares Kriterium 1];
- [überprüfbares Kriterium 2];
- [überprüfbares Kriterium 3].

Finde zuerst die vorhandenen Komponenten und Datenpfade im Quellcode. Verwende die eigene Oberfläche und Architektur der App so weit wie möglich. Implementiere dann die kleinste vollständige Version, baue sie, installiere sie auf dem angeschlossenen Smartphone und überprüfe jedes Kriterium selbst. Zeige das Ergebnis in einem Screenshot und liste die Kompromisse auf. Pushe nichts ohne eine eigene Anweisung.

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 keine Diagnose, sondern nur eine Beobachtung und die Forderung nach einem gemessenen Ergebnis:

Auf dem physischen Smartphone ruckelt der Feed, wenn während des Scrollens die Paginierung einsetzt. Reproduziere das selbst, miss ruckelnde Frames / Frame-Zeit, finde die Ursache, behebe sie, ohne das Feed-Verhalten zu verändern, installiere die APK neu und wiederhole dieselbe Messung. Erkläre die Aufgabe nicht allein deshalb für abgeschlossen, weil der Code kompiliert.

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.“ 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. Bitten Sie den Agenten vor dem Push, alle verfolgten Dateien und den vollständigen zu veröffentlichenden Verlauf nach geheimen Werten zu durchsuchen, den Diff zum Upstream zu zeigen, die Lizenz zu erhalten und eine Debug-APK nicht als offiziellen Client darzustellen.

Bereite die Änderungen für die Veröffentlichung vor, führe aber zuerst ein Sicherheits- und Lizenz-Audit durch.

Untersuche git status, git diff, jede verfolgte Datei und den vollständigen Verlauf, der veröffentlicht werden soll, auf meine echten TELEGRAM_API_ID und TELEGRAM_API_HASH, Tokens, Passwörter, Signaturschlüssel und private absolute Pfade. Gib keinen gefundenen geheimen Wert aus; berichte nur den Typ, die Datei und eine sichere Behebung. Prüfe, dass local.properties ignoriert wird und nie verfolgt wurde.

Vergleiche die Änderungen mit dem Upstream, bewahre Copyright-Hinweise und erfülle die Lizenzpflichten. Halte in der README fest, dass dies ein inoffizieller persönlicher Build ist, welche Versionen und ABIs getestet wurden, wo die Zugangsdaten lokal eingetragen werden müssen und wie die APK gebaut wird.

Zeige mir die endgültige Dateiliste und das Audit-Ergebnis. Committe und pushe erst nach meiner ausdrücklichen Freigabe.

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