Don't wait for the feature — change the app yourself

I wanted to open Telegram and see one feed of unread posts from only the channels I had chosen. That button did not exist. I did not file a request and wait to see whether it reached somebody else’s roadmap. I opened the official Android client’s source, described the behavior to Claude, plugged in my phone, and used my own build that evening.

That morning, the feature did not exist

Channel subscriptions tend to end in one of two equally bad states: hundreds of red counters, or everything marked read while useful posts disappear. I wanted a third model: choose a handful of channels myself, then read all their unread posts as one ordinary timeline.

The resulting Digest tab does exactly that:

• it lets you search for channels and combines their posts chronologically;
• it keeps a separate last-read boundary for every account;
• it opens at the first unread item and scrolls infinitely into the past;
• it renders channel names, media albums, dates, and reactions with Telegram’s own UI;
• it marks visible messages read through the same path as a normal channel screen.

This is not a tiny demo or a new client drawn from scratch. The agent had to move the base to the latest published Telegram source, understand its local database, pagination, media grouping, and navigation. But I did not have to dictate class names. I described what the person using it should see and feel.

The prompt specified behavior, not code

The core request looked roughly like this. The final sentence mattered: it stopped the agent from building a second, visibly foreign interface beside Telegram’s existing one.

Add a separate page containing all unread messages from Telegram channels I select.

I need a channel picker. Keep a separate Digest watermark for the last item I actually read. When the page opens, position it at the first unread message. Add infinite scrolling into the past and a bottom button that returns to the first unread item. Mark visible posts read through Telegram’s standard read state.

Render albums, the channel name, and its avatar the same way normal Telegram does. Reuse the existing UI as much as possible; write custom UI only where unavoidable.

Build the app, install it on the connected phone, and verify the result on the device.

A few hours later, the app was running on a Redmi Note 8 Pro. I then gave two short follow-ups: remove the scroll jitter, and move the round button above the bottom navigation while removing a stray avatar between messages. Claude inspected the result on the phone, found the causes, rebuilt the APK, and checked again. This felt more like working with a product team than “generating code.”

Code is getting cheaper; precise intent is getting more valuable

There used to be an expensive chain between “I need this” and “I use this”: find an Android developer, explain the architecture, assemble the environment, wait for builds, and learn ADB. That trained us to treat an app’s interface as final. We accept what the vendor ships and wait for the next version.

A coding agent changes the economics of that chain. It can read a large unfamiliar repository, match JDK, SDK, and NDK versions, locate the right integration point, build an APK, inspect an installation failure, read logcat, and repeat. Not every result is good, but the cost of a first working version has collapsed.

This does not apply to everything. A closed app with no source, server-side capability, payment infrastructure, or a cryptographic protocol change will not appear from one prompt. But when the desired behavior lives inside an open Android client and can be checked on screen, waiting for the official button is no longer always rational.

How to repeat it: leave only the necessary actions to the human

The workflow below is for this fork. You need a computer, a terminal-capable coding agent such as Claude Code or Codex, an Android phone, a USB data cable, and several gigabytes of free space. The repository is large, and the first Android build takes time. Let the agent prepare the technical environment; you will add private credentials, change phone settings, and sign in to Telegram.

1 Let the agent prepare the project

Open the agent in an empty folder and paste the prompt below. It deliberately stops before secrets and refuses to remove an installed app if Android reports a signature conflict.

Prepare https://github.com/howaihelps/tg-digest-android for a local build.

Work autonomously: clone the project, read its README, and inspect the Git history and working tree. Detect my OS and check Git, JDK 17, Android SDK / Build Tools 35, NDK 27.2.12479018, CMake, and platform-tools. Prepare anything missing; if a download or installation needs my permission, request it once and explain exactly why.

Never print, transmit, or commit TELEGRAM_API_ID or TELEGRAM_API_HASH. Verify that root local.properties is ignored by Git. If it does not exist, create a safe template containing only the correct sdk.dir and placeholders for the two values, then stop and ask me to fill them manually.

Do not build or push yet. Finish by reporting only the repository path, toolchain readiness, the local.properties path, and my next action.

2 Obtain your own Telegram API ID and hash

This is not a bot token. Telegram issues one pair per phone number and requires a personal ID for a third-party client. See Telegram’s official instructions.

At the cloned repository root, beside settings.gradle, open local.properties and replace the placeholders manually. Do not add quotes:

sdk.dir=/Users/[YOUR_NAME]/Library/Android/sdk
TELEGRAM_API_ID=[YOUR_NUMERIC_API_ID]
TELEGRAM_API_HASH=[YOUR_32_CHARACTER_API_HASH]

The sdk.dir path differs on Windows and Linux; the agent should already have filled it. In this fork, TMessagesProj/build.gradle injects the two values into BuildConfig, and BuildVars.java reads them at runtime. local.properties is listed in .gitignore.

At publication time, I also compared my real values against every file in both public commits: my personal api_id and api_hash are absent from both the current tree and Git history. The imported upstream source does contain Telegram’s standard restricted sample pair. Those are not my credentials, and you must not rely on them for your build.

3 Prepare the phone

Menu names vary by manufacturer. The basic sequence is documented in the official Android developer-options guide. Keep the screen unlocked during the first installation: an agent cannot approve a system dialog for you.

4 Ask the agent to build and launch

Once local.properties is complete and the phone is connected, send the next prompt. This is the launch instruction. The expected README commands are included, but you do not need to understand or run them yourself.

The credentials in local.properties are filled in, and the unlocked Android phone is connected over USB. Build and run the app on it.

Work until there is a verifiable result. Do not output TELEGRAM_API_ID or TELEGRAM_API_HASH, and before any Git action verify that local.properties is not tracked.

1. Run adb devices -l. If the status is unauthorized, ask me to approve the RSA dialog, then continue.
2. Check the ABI with adb shell getprop ro.product.cpu.abilist. This fork currently builds only arm64-v8a. If the phone does not support arm64-v8a, adapt the ABI configuration with the smallest change and explain it.
3. Prepare PATH, JAVA_HOME, ANDROID_HOME, and ANDROID_SDK_ROOT; reconcile the installed CMake version with Gradle.
4. Run ./gradlew :TMessagesProj_App:assembleAfatDebug. Fix environment or build errors instead of stopping at the first one.
5. Expected APK: TMessagesProj_App/build/outputs/apk/afat/debug/app.apk. Install it with adb install -r.
6. If installation is blocked, ask me to enable Install via USB. If Android reports a signature conflict, DO NOT uninstall the old app without my explicit approval: uninstalling erases its local data.
7. Launch package org.telegram.messenger.beta and verify that the first screen opens and the Digest tab is present. Use adb, logcat, and screenshots for diagnosis.

Finish by reporting the APK path and size, device ABI, installation result, launched package/activity, and what I should verify visually. Do not push anything.

The current configuration is verified on arm64-v8a: a debug APK of about 75 MB was built, installed, and launched as org.telegram.messenger.beta. On first launch, you still need to sign in to Telegram yourself and enter the login code and two-factor password if enabled. Do not give those to the agent.

5 Request your feature in the language of outcomes

After the app launches, you can change this fork or repeat the process with another open-source app. Do not start with “create a class” or “fix the RecyclerView.” Describe the situation, observable behavior, and acceptance criteria.

Change the app that is running on my phone for this personal workflow.

Problem: [what I currently do manually or what is missing].
Desired behavior: [what I should see and what should happen after each action].
Data and state: [what to store, when to update it, what must survive a restart].
Boundaries: [what must not change; which native screens and behaviors must remain].
Done when:
- [verifiable criterion 1];
- [verifiable criterion 2];
- [verifiable criterion 3].

First find the existing components and data paths in the source. Reuse the app’s own UI and architecture as much as possible. Then implement the smallest complete version, build it, install it on the connected phone, and verify every criterion yourself. Show the result in a screenshot and list the trade-offs. Do not push without a separate instruction.

6 Debug the feel, not just the compilation

The first Digest build worked, but the feed twitched slightly while loading more items. The next prompt did not contain a diagnosis — only an observation and a demand for a measured result:

On the physical phone, the feed jitters when pagination happens during scrolling. Reproduce it yourself, measure janky frames / frame time, find the cause, fix it without changing feed behavior, reinstall the APK, and repeat the same measurement. Do not call the task complete merely because the code compiles.

The agent found a full list refresh during pagination and replaced it with an incremental update. In the repeated measurement, janky frames fell from 11.9% to 2.1%, while the 99th-percentile frame time fell from 40 to 22 ms. I described another visual defect even more simply: “move the button above bottom navigation and remove the artifact in the center, while preserving the channel name.” The final compromise is a name-only header: the sender avatar that caused the artifact is not rendered. This loop — look, name the defect, let the agent reproduce it, then verify — matters more than a perfect first prompt.

Before publishing, use a separate security prompt

A working APK does not make a safe repository. Before pushing, ask the agent to scan tracked files and the complete published history for secrets, show the diff from upstream, preserve the license, and avoid presenting a debug APK as an official client.

Prepare the changes for publication, but first perform a security and license audit.

Inspect git status, git diff, every tracked file, and the full history to be published for my real TELEGRAM_API_ID and TELEGRAM_API_HASH, tokens, passwords, signing keys, and private absolute paths. Do not print any secret value you find; report only its type, file, and a safe remediation. Verify that local.properties is ignored and was never tracked.

Compare the changes with upstream, preserve copyright headers and license obligations. In README state that this is an unofficial personal build, which versions and ABIs were tested, where credentials must be entered locally, and how to build the APK.

Show me the final file list and audit result. Commit and push only after my explicit approval.

Telegram for Android is distributed under GNU GPL v2 or later, so the fork keeps the license and source available. There is also a practical obligation: maintain your fork, review its diff, and do not treat generated code as automatically trustworthy. An agent radically reduces the cost of implementation; it does not remove the owner’s responsibility.

Not an app for everyone — an app exactly for you

A mass-market product must choose features that make sense for millions. A personal build can be strange, narrow, and perfect for one person. This is where agents change software most: you do not have to found a startup or wait years for a feature-request vote. Sometimes an open repository, a precise description, a USB cable, and a willingness to inspect the result are enough.

Code did not become useless. It became much less scarce. The right to take it, change it, and run it on your own device became correspondingly more valuable.

Share on Telegram