How I Use Telegram to Update My Website

In 1999 I made my first website in Microsoft Word.

I didn’t know that’s what I was doing at the time. I just knew Word had a little “Save as Web Page” option, and I was a kid who wanted a page on the internet, so I typed some stuff, hit save, and out came an HTML file held together with more <font> tags than any sane person should produce. It looked terrible. It also worked. I was hooked.

That hook turned into a Computer Information Systems degree with an emphasis in website development, which turned into my senior year at Eastern New Mexico University, where I held the actual title of Webmaster. It’s a funny word now, the kind of title that dates you the second you say it out loud, like “disc jockey” or “typist.” But at the time it meant something specific: I used Dreamweaver and a lot of hand-coding to redesign half the university’s website, page by page, tag by tag, sitting at a desk for hours because that’s what the job required.

Last week I shipped a real change to a live website by sending a text message while I waited for my coffee to brew.

That’s not a metaphor. That’s literally what happened. The world is changing in a way I don’t think most people have fully clocked yet: what used to be a couple hours in front of my computer is now a message I can send from a kitchen counter before the coffee maker finishes beeping.

Here’s roughly how it works, in plain language, no architecture diagram required.

I open Telegram on my phone and type whatever’s rattling around in my head. Something like “the footer on the speaking page looks cramped on mobile” or “I want a short bio card on the homepage.” A bot on the other end turns my rough, half-formed idea into a properly scoped request, the kind of thing a developer would actually need to start work, not just a vibe. I read it, add one label, and that’s it. My part is done.

From there, a small crew of AI agents picks it up. One reads the existing code so it understands what it’s walking into. One writes the change. One reviews it. The system runs the same checks any competent team would run: does it build, does it pass the linter, does it actually look right on a real page. That last part matters more than it sounds. It opens the site, screenshots the pages that changed, desktop and mobile, so a broken layout gets caught before it ever reaches me.

Then it opens a pull request. Under its own GitHub identity, not mine. It cannot merge its own work. It can only ask.

So I get a notification, open GitHub, read the diff, and decide if I like it. If I do, I merge. That’s usually a couple of minutes of my actual time, reading something another system already built and checked. Merging kicks off a deploy on its own: the site builds, the database gets backed up first, everything migrates automatically, and there’s a health check waiting at the end that’ll roll the whole thing back if something’s actually broken. The system doesn’t take the agent’s word that it worked. It checks what actually landed on GitHub and goes from there.

The reason it’s Telegram and not some dashboard I have to remember to open: my ideas never show up when I’m sitting at a desk ready to work. They show up on a walk, in the shower, waiting for coffee. A phone in my pocket is the difference between an idea becoming a real change and an idea evaporating by the time I sit down and open my laptop and lose the thread.

I should say the honest part out loud: I didn’t build this because I think every company should run their website this way. I built it nights and weekends because I do product marketing for a tool in roughly this category, and I wanted to feel what agentic delivery actually feels like from the inside before I ever tried to sell someone else on it. If you want the real breakdown, what broke, what the guardrails actually catch, I wrote the deep dive at the software factory page. This post isn’t that. This one’s just about what it’s like to live on the other side of this shift.

I think about ENMU-Webmaster-Greg sometimes, the kid who thought knowing Dreamweaver’s code view was a genuine competitive advantage. I don’t think he’d believe this. Not because the result is more impressive, a cramped footer fix isn’t exactly a redesign, but because of where the work now happens. It used to live entirely at a desk, in a tool, in my hands. Now the work happens mostly without me, and my actual job is to notice an idea, say it out loud, and then decide if what comes back is good.

That’s not a smaller version of building a website. It’s a different job entirely. I just haven’t found a new title for it yet. Webmaster’s taken, and it was never really about the title anyway.