June 2026: What I Wrote, and Why

In June, I started writing on this blog again after a long break. I had rebuilt the site and changed how I published. Around the same time, I launched ProductLog. That month's articles explained why I had built both and how I wanted to use them.

As I returned to writing, I wanted to share more of the decisions behind my projects and the problems I ran into. That led to articles about why I built ProductLog, camiler.org's traffic without revenue, and the work I still had to do when using AI. I also wrote a more personal piece about my daily routines.

Making publishing less of a chore

Maintaining the old WordPress installation had become enough of a burden to put me off writing. The blog had been quiet for a long time. When I rebuilt the site in June, I changed the publishing process too.

In my article about moving from WordPress to Nuxt, I explained that I had changed more than the framework. What I wanted to write about had changed as well. Some of the installation and configuration guides I used to write no longer interested me.

As lists of commands became easier to find, I cared more about explaining why I had put a particular list together. Where had it helped? Which option had I chosen? What had I tried that did not work? I wanted the new blog to cover my projects, decisions, and failures. I still saw value in technical guides, but I was reconsidering why I should spend time maintaining an article that simply listed commands.

I had previously been reluctant to publish through Markdown and Git. Preparing files, managing images, fixing links, committing, and pushing all seemed like extra work standing between me and an article. Having an AI assistant help with those steps changed the calculation. I could explain an idea and get help preparing the text. I still had to check the resulting page and what the text actually said.

I also revised old articles before the site reopened in June. The August review of my content portfolio that appears in the migration article today was a separate, later exercise. I do not count it as part of the initial work I did when returning to the blog.

At the end of that article, I said time would tell whether the new setup would help me write more often and in greater depth. The first gain was more modest: the publishing infrastructure was less of an obstacle to writing.

A place for the work between launches

The blog suits an idea that needs room to develop. I did not want to bring every small change in a project here. I did not want those changes to disappear either.

That was how I explained why I built ProductLog for myself first. Across several projects, I wanted somewhere to record what I had released, which decisions I had abandoned, what I had changed, and why. Work happens between launches too. I wanted to write about it without having to turn every part into a story designed to attract attention.

ProductLog had no outside funding, and I could give it about an hour a day. I was its first user. A snag I encountered while using it became a specific problem to fix. Knowing I would want to document future projects gave me a reason to keep going. It did not prove that the platform would survive or that other people would need it.

The other ProductLog articles that month explored the risk of being so open. I was building a platform to help people explain their work more clearly. The same record could make it easier for a competitor to understand what I was trying to do.

That led me to write about the tension ProductLog created around sharing my work. Explaining the reasoning behind a decision and revealing every detail of an untested plan were different choices. The first version made overly definite claims about copying; I narrowed them in later revisions. The question remains: how much do I need to reveal to explain a lesson to a reader?

More output still leaves me with work to understand

AI's help was tangible in projects I ran alone, such as ProductLog. Using those tools almost every day, I found that working faster still left me with things I needed to understand.

My article on comprehension debt grew out of the gap between working code and a system I could explain. The code might compile and the tests might pass, yet I might not understand well enough why a decision had been made or what a change would affect.

When I work alone, there is no second person who automatically holds the knowledge I lack. I accept the agent's suggestion, and I am the one who has to investigate a problem later. That was why, in June, I wrote about stating the intent before writing code and being able to explain why the work I accepted existed. Producing more also meant taking responsibility for that output.

At the company, the same change in capacity affected another decision. In my article about hires that never happen, I described how some projects that used to wait for a new budget and team could start with the existing team. The case for opening a role could change without an employee being laid off.

That observation came from the workplace where I made decisions. It did not measure changes across the whole labour market. Research I added later broadened the discussion. My starting point in June was something I could see from inside the company, but that layoff counts alone could not show: which work can we now start without hiring someone?

An impressive chart can leave a question unanswered

The figures in my June review of camiler.org were substantial: about one million search impressions a month, more than ten thousand clicks, and zero dollars in revenue. Those were the project's results as I recorded them then, not its performance today.

In my account of the programmatic SEO experiment, I explained that the data and publishing pipeline I had built could gain visibility. My expectation of earning advertising revenue had not been met. The AdSense application had been rejected. Getting a place in search results had not settled which revenue model that traffic could support.

In the AI visibility articles, I also looked at what a chart could tell me. In my analysis of Bing Citation Share, I tried to distinguish between the first-party data for sites I managed and visibility scores based on selected queries. Then the Google data failed to fit my explanation that pages were fetched live when a query was made.

In the follow-up where I revised my theory, I had to separate observation from explanation. Removed content appeared to lose visibility in AI results before it did in search. The same report could not establish exactly how that happened. In the original text, I had also concluded that Google used a separate AI index. I narrowed that claim in a later revision: a delay in visibility did not prove how the system was built internally.

The blog was back; my daily routines were not

Alongside these accounts of work, “One Victory, Several Defeats” took stock of something quite different. After six years without smoking, I had started again and then quit again. When I wrote the article, I had not smoked for two months. But I had gained weight, had not made walking a habit, and was barely touching the violin.

I had launched ProductLog, rebuilt the site, and returned to writing. Progress on those things did not show that I was looking after myself any better. I had no solution yet in that article. The new site and product had not made up for the gaps in my daily routines.

Reading June's articles together now, I can see that I wrote as much about the questions my completed work left open as about the work itself.