The installer took minutes. The real work was turning a blank WordPress instance into a coherent site, deciding what AI could safely change, and making the result feel like mine.
This morning, this site was not a finished publication. It was a hosting account, a domain, some old files, and a rough idea: I wanted a place to write about software, systems, and the work that happens between an initial idea and a dependable product.
By the end of the day, WordPress was installed, the old site was preserved, the design had gone through several revisions, the major pages shared one visual system, the first long-form article was live, and the Contact page had useful links instead of a polite placeholder.
I did it with an AI agent working alongside me. That sentence is accurate, but it is also incomplete. The interesting part was not watching AI push buttons. It was learning how to divide the work between automation and judgment without giving up control of either.
The installer was the shortest part
The hosting control panel had a built-in WordPress installer. Once I was signed in, the mechanical part was familiar: choose the primary site, create the WordPress instance, finish the initial administrator setup, and confirm that the dashboard and public site loaded over HTTPS.
An AI agent can help with that sequence, but there is not much intelligence required by the installer itself. It is a form with consequences. The meaningful questions come before and after it: What existing content could be replaced? Was there a recoverable backup? Which domain was canonical? Would a change disturb email or DNS? What exactly would be rolled back if the result was wrong?
We started by treating the old site as something worth preserving, even though I intended to replace it. That may sound overly careful for a personal blog. It is also the same habit that prevents an ordinary website task from turning into an avoidable incident.
The first design was wrong
The first version looked like a WordPress site that had just been installed. It was functional, clean enough, and completely unconvincing. The next version was darker and more technical, but it still did not feel right. It used too little of the screen, the page widths varied, the header and footer did not line up, and the provisional site name became more prominent than the work itself.
This was where the collaboration became useful. I did not need to describe every CSS property. I could say what bothered me in ordinary language: too much wasted space, the article is too narrow, the bottom does not align with the top, this page does not look like the others. The agent could inspect the rendered page, measure the layout, identify which block or template introduced the mismatch, and propose a correction.
But the agent could not decide whether I wanted my name across every page. It could not know that a technically tidy design still felt impersonal, or that a name I liked an hour earlier had started to irritate me. Those were not implementation defects. They were editorial and aesthetic decisions, and I had to make them.
The useful shift: stop fixing pages
At first, it was tempting to repair each page independently. The Home page needed one adjustment. The Writing page needed another. The article template was too narrow. Contact had its own spacing. That approach produces quick visual wins and a maintenance problem.
I eventually gave a more important instruction: step back, define one standard, and work through the templates. The shared header, footer, content shell, typography, colors, buttons, and responsive rules became the system. Individual pages could still contain different material, but they were no longer allowed to invent a different site around it.
That changed the work from a collection of visual patches into a small design system. It also made the AI more effective. A clear standard reduces ambiguity. Instead of asking whether every page looked acceptable, we could ask whether every route honored the same measurable rules.
Giving AI just enough access
The initial installation happened through the control panel and WordPress dashboard. Once the site existed, repeated edits through a graphical editor became slow and error-prone. WordPress has an API, so I created a dedicated application credential and let the agent use the supported interface for tightly scoped changes.
The important word is scoped. The credential was not pasted into prompts, source files, issue comments, or the public site. It remained outside the project. Temporary scripts received access at runtime, performed one defined operation, verified the result, were scanned for credential material, and were removed.
This was less dramatic than handing an agent the keys to everything, and much more useful. It could create a private draft, update a page, or standardize a template without touching DNS, email, billing, or unrelated hosting resources. Access was a tool, not a blanket permission.
The unglamorous part was the important part
Every meaningful change followed a small transaction: inspect the current state, preserve a rollback point, describe the exact scope, apply the change, purge the cache, verify the public page, and remove temporary working files.
We checked the canonical HTTPS route without an administrator session. We looked for stale placeholder text, broken links, server errors, and accidental admin markup. We compared the live content hash with the preserved rollback hash. We inspected desktop layouts and rendered narrow pages in a fresh browser profile to make sure cards stacked and navigation still fit.
None of that makes an impressive demonstration. It does make the result trustworthy. Generating a plausible page is easy. Knowing which version is actually public, whether the cache cleared, whether the old version can be restored, and whether the mobile layout survived is the work.
What the AI contributed
The agent was good at maintaining context across several kinds of work. It could read the existing site, inspect WordPress block markup, trace a width problem to a nested constrained group, draft copy, use the API, and then test the public result. It also kept a durable record of decisions and validation instead of leaving the important details in a chat transcript.
It was particularly useful when I knew the symptom but not the implementation detail. When I said that an article occupied roughly a third of the screen, the right response was not a lecture about ideal line length. The agent measured the actual content column, found the template constraint, and changed the standard. When I said that Contact did not match, it compared that route with the shared shell and removed the page-owned exception.
AI also made iteration cheaper. I was willing to reject a design because changing direction did not mean starting a week-long cycle. That freedom is valuable, provided it does not become an excuse to make unreviewed changes faster.
What stayed human
I chose what the site was for, what it should say, which parts of my background belonged on the landing page, and which contact methods I was comfortable making public. I decided that the blog should feel like a technical notebook rather than a personal billboard. I rejected versions that were perfectly valid and still wrong for me.
I also remained responsible for the consequences. An agent can recommend a backup and prove that a hash matches. It cannot assume the risk on my behalf. It can draft a paragraph in my voice, but I own the sentence once I publish it.
That is the line I find most useful: AI can extend attention, memory, and execution, but it does not remove authorship or accountability.
What I would do differently next time
I would define the design tokens and page-width rules before polishing individual pages. I would settle the site identity later, after seeing real content in the layout. I would establish the supported API path as soon as the initial login and recovery controls were in place. And I would keep the separation between content hosting and application hosting explicit from the beginning.
I would still iterate. The first answer is rarely the right one in design or writing. But I would iterate inside a system sooner.
Where the day ended
The result is not a finished brand or a permanently frozen design. It is a coherent working site with a maintainable template, a place for long-form technical writing, a useful About page, real contact paths, responsive behavior, and a rollback trail.
It was built faster because I used AI. It became mine because I kept disagreeing with it.
This post was drafted through the same workflow it describes. The agent assembled the first version from the day’s record. I reviewed the argument, the details, and the voice. That feels like an honest description of the work: assisted, iterative, and still my responsibility.