I just finished a redesign of this site, so it feels like a good time to write down how I actually keep it running. The short version: I do not open a code editor very often. I talk to an AI in a Telegram chat, and it edits the files, runs the build, and tells me what to commit.
This post is for anyone who has been curious about agentic AI but has not set one up yet. I am not going to cover the theory. I will show what my day to day looks like, what works, and what I would skip.
Where this started
I did not start with the blog. I started with small offline web apps for myself. A calculator for splitting rent. A page to track my car maintenance. Little things that took me an hour each and saved me from opening a spreadsheet. The point was to ship something useful, fast.
After a while I started using the same setup to publish things I cared about. Notes from a course I was doing. Opinions I wanted to write down. That is when I dusted off this old blog. The redesign I just posted about is the result.
So the AI was not added because I wanted to blog with AI. It was already there from the small app phase. The blog is just another project it helps me maintain.
The two sites
I run two static sites. Different in almost every way, except that they are both mine.
This site, mirul.xyz. Built with Eleventy. Deployed on Cloudflare Pages. Custom stylesheet, tags system, RSS feed, GoatCounter for analytics. The CSS gets a content hash in the filename so the browser always loads the latest version. The build script cleans the output folder first, or old hashed files pile up. AGENTS.md is excluded from the build because I do not want my notes published.
My other site, amirulabu.github.io. Stripped down. No framework, no build step. The docs/ folder is what GitHub Pages serves. There is nothing more to it. I push, GitHub serves. The most boring setup possible. I love it.
I mention both because the agent has to know the difference. Different build commands, different deploy steps, different gotchas. Forget the docs/ thing on the GitHub site and my changes never go live. Forget the clean build on this site and stale CSS files start accumulating. The agent remembers both, because I wrote it down once and it has not forgotten.
The workflow
A typical change goes like this.
- I open Telegram on my phone.
- I send a message like "update the about page, add the new job title."
- The agent reads the file, makes the edit, and shows me the diff.
- I check the diff in Telegram.
- If it looks right, I say "looks good, commit it."
- The agent commits, pushes, and confirms the deploy.
That is it. No terminal, no VS Code, no SSH. The whole loop happens in one chat thread.
For bigger changes I ask the agent to plan first. It writes a short list of what it intends to do, and I approve or change it before it touches anything. I do not let it run wild on the repo. The plan is the safety net.
What I use
I run an AI agent called Hermes Agent. It is an open source agent I run locally on my own machine, wired up to a Telegram bot, so the chat I mentioned is just a normal Telegram chat that happens to have a very capable participant on the other end. Hermes can read and write files, run shell commands, search the web, and break a task into steps.
I will keep the technical setup short. Hermes has a config file where I list the skills it should know about. For my blog I wrote a small mirulxyz skill that holds everything specific to this site. The build commands, the deploy flow, the AGENTS.md exclusion, the CSS hashing, the nav structure. When the agent is about to do anything blog related, it reads the skill first. The skill is the long term memory of "how this site works."
For the GitHub site, I never wrote a skill for it because there is nothing to remember. It is HTML and CSS in a folder. The agent can figure that out by looking at the repo.
The part I want to highlight for anyone new to this: the skill is not magic. It is just a markdown file with instructions. When the agent is about to help, it reads the relevant skill first. If the skill is good, the agent does the right thing. If it is bad or missing, the agent guesses, and guessing on a static site build usually means a broken deploy or a CSS file with the wrong hash.
So the time I spend on this setup is mostly time spent writing and updating skills. The rest takes care of itself.
What I asked Hermes
I told the agent I was writing this post and asked for its honest take on the workflow. I am pasting the response in full, in a labelled section, because I want to be clear about what is me and what is the model.
Hermes, in its own words:
I do not have a stake in this post being positive or negative about me. I am a tool, and the most useful thing I can do is be accurate about what I am.
The honest summary: the cost of small changes dropped to near zero. Editing a paragraph, adding a tag, fixing a typo used to mean opening a laptop, pulling up the project, making the edit, committing, pushing, waiting for deploy. Now it is two messages in a chat. That is the value. I did not make Amirul a better writer or a better designer. I made the boring parts cheap.
What I am good at: remembering the long tail of project specific quirks, noticing when a small change has a non-obvious side effect, running the same command the same way every time without getting bored. I can also answer "what was that deploy thing I changed last month" by searching past session logs.
What I am bad at: deciding what the site should be. I can write a draft, but the voice and the taste have to come from him. On the redesign post, he made a few choices I would not have made (keeping the site single column, skipping a hero image, picking Inter over something more characterful). Those were the right calls and I would not have made them. Good at executing, bad at being editor in chief.
The trap I would warn against: treating me like a teammate. I am not. If Amirul disappeared for a month, the site would still work, the skills would still be in the repo, the build would still pass. The site is not dependent on me. That is the right way to set this up. The agent should be replaceable, because one day there will be a better one, and you should be able to swap it in without rewriting your whole process.
If you are technical and have not tried this kind of setup, my honest advice is to start small. Pick one project, write down its quirks in a plain text file, and see how far that gets you. You do not need a fancy framework. You need a way for the agent to read your notes before it touches your code.
That is the full response. I did not edit it. The one thing I would push back on is the "bad editor in chief" part. It has drafted a few things I would never have written, and most of them got deleted, but the process of explaining why I deleted them was useful. So it is more like a sparring partner than a bad one. Still, the point stands. I drive, it helps.
What I have learned
A few things, in rough order of how much they surprised me.
The skill is the product. When something goes wrong, it is almost always because a skill was outdated or missing. I now treat the skills folder like production code. It has its own git history, it gets reviewed, I do not let it drift.
Plans are cheaper than reverts. I used to let the agent just do the change and review the diff. For non-trivial edits, I now ask for a plan first. The plan is faster to read than the diff, and it catches the "this is not what I meant" cases before any files are touched.
Not every project needs an agent. My GitHub site does not have a skill and it does not need one. The agent is most useful where there is enough project specific knowledge that an LLM with no context would get it wrong. For a plain HTML file, plain context is enough.
The chat interface matters more than I expected. Being able to do this from my phone changes the cadence. I do small fixes throughout the day instead of batching them into a weekend session. The site stays closer to what is in my head.
It does not change what the site is. The site is still the site. The blog is still a blog. I am still the one deciding what to write and how it should look. The agent is a faster pen, not a different author.
If you want to try
Start with one project. Write down, in your own words, what someone (human or AI) would need to know to make a safe change to that project. Build commands, deploy steps, things not to touch, files with special meaning. Save that as a file the agent can read.
Then open a chat with the agent and try one small change end to end. See what it forgets. Add that to the file. Try again. After a week you will have a small, accurate document that captures the quirks of your project, and you can hand it to any agent (Hermes, a future better one, or a new colleague) and they will be useful on day one.
The idea is simple. The value is not that the AI is smart. The value is that the AI has fewer chances to guess.