{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreifppfrj5lln2ia5uxbzhzj74yf7qf2j4gy2zjra7qp3ypjrgb2gcq",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpne2z2yyr22"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreic3h3uik637rekpmsr46yab5y26tzahmuzy7n6dopxnrloab6b2ne"
},
"mimeType": "image/webp",
"size": 60394
},
"path": "/shreyshah/telegram-is-becoming-my-control-plane-for-vibe-coding-5mo",
"publishedAt": "2026-07-02T05:39:43.000Z",
"site": "https://dev.to",
"tags": [
"ai",
"programming",
"productivity",
"devtools"
],
"textContent": "_The IDE is where code changes. Telegram is where the loops run._\n\nTelegram is becoming the control plane for vibe coding.\n\nThe IDE is where code changes. Telegram is where the loops run.\n\nI know that sounds a little ridiculous. Coding is supposed to happen in an editor. You open Cursor, talk to the agent, review the diff, run the tests, and keep going until the thing works.\n\nThat was my workflow for a while too.\n\nBut after using coding agents every day, the split became hard to ignore. The place where code changes and the place where agents are managed do not need to be the same place.\n\nThe IDE still matters. Cursor matters. Claude Code matters. Codex matters. I still use all of them. But when agents start doing more of the work, I do not want to live inside the surface where the code is being edited. I want to manage the loop.\n\nThat is where Telegram started making more sense than I expected.\n\n## My coding interface kept changing\n\nI have been vibe coding for about 6 years now.\n\nI started with GPT-2 inside TabNine. Then GitHub Copilot brought GPT-3 into the editor. Then ChatGPT made coding conversational. Then Cursor moved the AI directly into the IDE. Then Composer made multi-file changes feel normal.\n\nAfter that, the stack got strange. Claude Code, Codex, Cursor agents, cloud agents, loops, OpenClaw, Hermes, cron jobs, review agents, and software factories all became part of the workflow.\n\nEach interface solved a different problem. Copilot made autocomplete useful. ChatGPT made coding conversational. Cursor made AI feel native inside the IDE. Composer made multi-file edits feel normal. Claude Code and Codex made agent execution feel real.\n\nHermes solved a different layer for me. It became the personal orchestrator above the coding tools, the thing I could teach, redirect, schedule, and use to coordinate other agents.\n\nTelegram then became the interface I could actually live inside while managing that orchestrator from my phone.\n\nThat last part changed more than I expected.\n\n## The laptop assumption is still everywhere\n\nMost AI coding tools still quietly assume the human is sitting in front of a coding interface.\n\nThat is true even when the agent is doing the work somewhere else, the tests are running on another machine, the branch was created by a background process, another agent is reviewing the output, and the only thing I need to do is approve, reject, or redirect a pull request.\n\nThe assumption is still simple: the human is at the desk.\n\nThat starts to feel wrong once you use agents seriously.\n\nIf an agent can create the branch, write the code, run the tests, inspect the failure, trigger review, and loop on fixes, why am I still forced to manage the system from a laptop?\n\nThat question pushed me toward Telegram.\n\nNot because Telegram is a coding app.\n\nBecause Telegram gives me mobile context management for coding agents.\n\n## Telegram solves context for me too\n\nPeople talk a lot about context management for agents.\n\nThey should. It matters.\n\nBut there is another context problem that gets less attention: the human's context.\n\nWhen you are working across multiple projects, agents, repos, branches, terminals, cloud workers, and review loops, your own memory becomes the bottleneck. You forget which terminal had the important log. You forget which agent was working on which repo. You forget which thread had the decision. You forget whether the bug is still being investigated, already fixed, or waiting on your approval.\n\nA good agent interface should help the model remember. A great one should help the human remember too.\n\nTelegram does this weirdly well.\n\nFolders become project areas. Groups become projects. Supergroups become workspaces. Topics become features, bugs, and experiments. Threads become isolated context. Agents report into the right place.\n\nThe whole system becomes glanceable from a phone.\n\nThat is the part I care about most. Mobile is not a convenience layer here. Mobile changes the workflow.\n\nI can be away from my laptop and still understand what is happening. I can make judgment calls without reopening an IDE. I can keep work moving without remembering which machine, tab, terminal, branch, or chat window had the state.\n\nThe thread is the workspace. The group is the project. The phone is the control plane.\n\n## Hermes is the layer that makes this work\n\nTelegram alone is not the system.\n\nTelegram is the interface. Hermes is the orchestrator.\n\nI use Hermes as my personal agent. I can teach it how I work, how I want projects managed, how to run loops, how to use cron jobs, how to route work to other agents, and when to escalate back to me.\n\nThe pattern usually looks like this:\n\n 1. I give direction in Telegram.\n 2. Hermes turns that direction into a loop.\n 3. Cron keeps the loop alive.\n 4. Poly agents coordinate the work.\n 5. Codex, Claude Code, Cursor, and other agents execute pieces of the task.\n 6. Review agents inspect the output.\n 7. The loop keeps going until the result is usable.\n 8. I get pulled in only when judgment is needed.\n\n\n\nThat creates a very different relationship with coding.\n\nThe old workflow was simple and exhausting: the human drives every step, reviews every line, catches every mistake, and keeps all the project state in their head.\n\nThe new workflow is closer to this: the human defines the goal, sets the boundaries, decides what good looks like, and reviews exceptions. The system does the execution work.\n\nThat is why I keep coming back to the word harness.\n\nThe best AI coding setup is not the smartest single agent. It is the harness around the agents.\n\n## The real skill is removing yourself from the loop\n\nThe skill required to work with AI agents is changing.\n\nWhen the models were weaker, the skill was staying in the loop. You had to review every line because the models were brittle. You had to drive every step because the agents lost the plot. You had to catch every mistake because there was no reliable review loop behind them.\n\nThat is still true in some workflows.\n\nBut with the current models and current agent capabilities, the human often does not need to be inside every loop.\n\nThe agent can write the code, run the test, inspect the failure, ask another agent to review it, open the pull request, and try again when the review fails.\n\nSo the question changes.\n\nIt is no longer only: how do I prompt better?\n\nIt becomes: where am I still blocking the system for no good reason?\n\nThat question is uncomfortable.\n\nBecause removing yourself from the loop does not mean being careless. It means building a system that can operate without you babysitting every step.\n\nThat takes real engineering. You need clear goals, context boundaries, review paths, escalation rules, memory from past mistakes, and a way for agents to report progress without dumping noise everywhere.\n\nYou also need a way for the human to re-enter the loop at the right moment, not every moment.\n\nTelegram works well for me because it gives that system a place to live.\n\n## Why this feels like a mobile ADE\n\nWe already have IDEs: Integrated Development Environments.\n\nThey were built around a developer writing, editing, navigating, debugging, and compiling code directly. That still matters.\n\nBut agent development needs another kind of environment.\n\nAn ADE.\n\nAgent Development Environment.\n\nNot just a place where code changes. A place where agent loops are managed.\n\nOn desktop, that might be a terminal, an IDE sidebar, a cloud dashboard, or a coding agent interface. On mobile, Telegram is the best version I have found so far.\n\nIt already has the primitives I need: project folders, persistent groups, topic based threads, notification control, search, media, files, voice messages, bots, human escalation, and multi-agent reporting.\n\nNone of those were designed specifically for coding agents. Put together, they form a surprisingly good mobile environment for managing them.\n\nThat is why Telegram feels less like a chat app in my workflow and more like a control plane.\n\nThe IDE is where the code changes. Telegram is where the loops run.\n\n## What people miss about this\n\nThe obvious reaction is: why not just use the agent UI?\n\nCursor has a UI. Codex has a UI. Claude Code has a terminal. Cloud agents have dashboards. Some of them even have mobile apps now.\n\nI have tested that path.\n\nThe mobile apps help, but they still feel like thinner versions of the same agent product. You are usually inside one tool, one agent, one execution surface, or one task thread.\n\nThat is useful. It is not the same thing as managing the system above the agents.\n\nMy workflow is not one agent.\n\nIt is agents managing agents.\n\nHermes creates loops. Cron keeps those loops alive. Poly agents route work. Codex, Claude Code, Cursor, and other tools do execution. Review agents close the loop.\n\nI step in when my judgment is needed.\n\nA single-agent UI is not enough for that. A mobile app for one coding agent is still mostly a remote control for that one coding agent.\n\nHermes plus Telegram feels different because it gives me the layer above the agents.\n\nTelegram gives agents clean context. It gives me clean context. It gives me groups, topics, files, voice, search, notifications, and now even streaming messages from agents in the same mobile surface I already use all day.\n\nThat is the UX difference for me.\n\nIt is not just mobile access to an agent. It is mobile context management for a whole agent system.\n\nAnd maybe most importantly, it pushes me to think about software work as a system of loops instead of a sequence of prompts.\n\n## Where I think this is going\n\nI think more AI coding work is going to move in this direction.\n\nNot everyone will use Telegram. That is not the point.\n\nThe point is that the next important interface might not look like an IDE. It might look like a control plane: a place where the human defines goals, checks progress, approves exceptions, and manages agent loops from anywhere.\n\nThe IDE will still matter. The code has to change somewhere.\n\nBut the center of gravity is moving.\n\nFor me, it moved from writing code in an editor to managing loops from my phone. That changed how I think about AI coding as a skill.\n\nThe best setup is not the smartest model, the flashiest IDE, or the agent that writes the most code.\n\nThe best setup is the harness around the agents: the memory, the review loop, the escalation path, the context boundary, and the interface that lets the human stay free without losing control.\n\nFor me, right now, that interface is Telegram.",
"title": "Telegram is becoming my control plane for vibe coding"
}