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 is: I do not open a code editor very often. I talk to an AI in a Telegram chat, and the AI 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 will not go deep into theory. I will show what my day to day looks like, what works, and what I would not bother with.
Where this started
I did not start with the blog. I started with small offline web apps for my own use. A simple 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 to myself, 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 and gave it a new breath of life. The redesign I just posted about is the result of that.
The point is: the AI was not added because I wanted to blog with AI. The AI 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. They are different in almost every way except that they are both mine.
This site, mirul.xyz. Built with Eleventy. Deployed on Cloudflare Pages. Has a custom stylesheet, a tags system, an RSS feed, GoatCounter for analytics, the works. The CSS gets a content hash in the filename so the browser always loads the latest version. The build script cleans the output folder before building, or old hashed files pile up. AGENTS.md in the repo 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. That is the whole deployment story. I push, GitHub serves. It is the most boring setup possible and I love it.
The reason I mention both is that the agent has to know the difference. Different build commands, different deploy steps, different gotchas. Forgetting the docs/ thing on the GitHub site would mean my changes never go live. Forgetting the clean build on this site would mean stale CSS files accumulating. The agent remembers both because I wrote it down once and it has not forgotten.
What the workflow actually looks like
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 runs the commit, pushes, and confirms the deploy.
That is it. I do not pull up a terminal, I do not open VS Code, I do not SSH anywhere. The whole loop happens in one chat thread.
For bigger changes, I sometimes 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. If you have heard of OpenClaw, it is somewhat like OpenClaw — an open source agent you run locally on your own machine, that you wire up to a chat interface, and that does the same kind of work. Hermes can read and write files, run shell commands, search the web, and break a task into steps. I have it 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.
The technical setup is not the point of this post, so I will keep it 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 needs 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 from looking at the repo.
This is the part I want to highlight for anyone new to agentic AI. The skill is not magic. It is just a markdown file with instructions. When the agent is about to help with a task, it reads the relevant skill first. If the skill is good, the agent does the right thing. If the skill 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 is: the cost of small changes dropped to near zero. Editing a paragraph, adding a tag, fixing a typo — those used to be "open laptop, pull up the project, make the edit, commit, push, wait for deploy." Now it is two messages in a chat. That is the entire value proposition. I did not make Amirul a better writer or a better designer. I made the boring parts cheap.
The things 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 am also good at answering "what was that deploy thing I changed last month" by searching past session logs.
The things 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. I have noticed that 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. I am a good executor and a bad editor in chief.
The one 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, and 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 you 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 only 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 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 will be able to hand that to any agent — Hermes, a future better one, or a new colleague — and they will be useful on day one.
That is the whole pitch. It is not about AI being smart. It is about writing things down so the AI does not have to guess.