By Ryan Cecil
27 July 2026
In Part 1, Gabriel and I described the steps to publish a site with Pitt's free hosting service. Here, I want to give an honest account of building my initial HTML files with Claude, including where it helped and where it fell short. Claude was chosen as the AI collaborator of choice because Pitt provides free access to students.
Before this project, I had some experience playing around with building personal websites, so I already had a few features in mind. I wanted: (1) to use a static site generator, so that I could add items to the site without editing HTML directly; (2) those items to be written in org-mode, a markup language similar to Markdown but designed for the Emacs editor; (3) a few different types of pages, including a CV-style homepage, a publications page, a research page, and some others; and (4) the site to incorporate org-roam, which would let me link items together and automatically generate "Related Items" sections, so that visitors could easily jump between related projects, research, and publications.
To build the site, I gave Claude specific instructions outlining the features I wanted. I also attached some entries from my CV as example items to initially populate the site, and I gave it Pitt's hosting steps so that it knew what format the HTML needed to be in. After thinking for a minute or two, Claude produced a fully functional template that, combined with the static site generator Hugo, generated the HTML files of a working site.
The first version did not look quite how I wanted, so I began refining it in plain language, with requests like "use a serif font similar to a statistics paper" or "move the publication link next to the publication title." When I pasted in a few researcher websites I admired, it adopted a similar clean, text-forward style. Once the site looked the way I wanted, I added other features to suit my workflow, such as an "In Progress" label and a one-command deploy to Pitt's servers. Most of this is not necessary for a personal website; the point is that an AI collaborator makes this kind of customization far more accessible.
When errors came up, I used Claude to help debug, either by asking it to fix the error directly or by asking how to modify a particular part of the code myself. Claude could not run the site itself, so every change had to be tested on my machine, and occasionally the changes it made contained mistakes. For example, a future graduation date silently removed my PhD experience because the site hid future-dated content by default. An automatic cleanup step crashed the preview server. My profile photo would not upload, due to a quirk in how the copy command handled folders. And several links worked locally but broke once deployed, because Pitt serves each site from a ~username/subpath that the code had not accounted for. Each issue was fixed quickly with the help of Claude.
Overall, my experience building a personal website with Claude was a good one. It quickly gave me a base template to work from, helped me understand the code, and assisted with each iteration. It was particularly helpful for refining the site's appearance, both from the examples I gave it and from small quirks I noticed along the way. That said, some errors were only able to be partially fixed by Claude. This experience was consistent with how I try to use these models in general: they are strong collaborators for building and explaining, but the verification remains my responsibility.