August 2026: What I Wrote, and Why

In August, I published a series of articles about companies' AI projects. I discussed model selection, data, authority, and measuring results as separate decisions. In the same month, I returned to systems I had built in the past and older articles on my own site.

Among those articles was one about a hotel review I had forgotten to write after a holiday. It seems a small matter alongside enterprise AI. But that article also looked at the gap between agreeing to do something and actually doing it. I had enjoyed the stay and was willing to write a review. Getting it written still took more than that first conversation.

A happy guest still has a task to finish

When we left the hotel on August 7, we told the staff we had enjoyed our stay. They gave us cards with QR codes so we could write a review on TripAdvisor. “Of course, we will,” we said. We went home, unpacked, returned to work, and got ill. Fifteen days later, we had forgotten about the review.

Nothing bad had happened at the hotel. Nobody had been rude. We intended to write a review, but we did not write it. That small gap was the starting point for August's customer experience article.

In my article about helping a satisfied customer leave feedback, I wrote from the customer's side. I had known for years, through my work, how important it was to ask satisfied customers for reviews. Now I had seen in my own life how I could agree to leave one and then fail to do it.

I thought a polite reminder a few days later might have helped. It was a suggestion in the article. I cannot say such a message would definitely have led me to write the review. I might still have forgotten.

In that article, I suggested only a limited role for AI. It could make it easier to build a small piece of software that brings follow-up tasks to the guest relations team. The team that understands the work should decide whom to contact, when, and under what conditions. The system also needs to account for a customer who has already left a review, does not want to be contacted, or has an unresolved problem.

Writing the article prompted me to finish the job I had forgotten. I went to TripAdvisor and posted my review.

The decisions that come before choosing a model

The enterprise AI articles began with a related question: what work are we asking the system to do? In my article on why an AI project should not start with model selection, I distinguished a model that produces good answers from a company being able to carry out a task reliably. Explaining refund terms to a customer and initiating a refund require different scopes of responsibility.

I explored that starting question in separate articles. Which part of the process can follow explicit rules? Where does unstructured text need to be understood? Where is the information kept, and how current must it be? Does the model actually need to choose the next step?

I used Vanity, REDAR, and bank integration to explain AI's place in process automation. The rules for assigning leads were complex but known. REDAR needed a model to handle its unstructured text. For bank transactions, a service that would maintain the connections was useful. The same technology choice could not cover all three.

In the articles on fine-tuning and RAG, I separated giving a model current information from adapting its behaviour through examples. Reading a current order record and finding the relevant passage among thousands of documents are different needs. That was also why I wrote separately about whether the data is sufficient for a particular decision. A table might support a monthly report without being sufficient to issue a binding quote to a customer.

I explained the difference between a workflow and an agent in terms of who chooses the next step. If the steps are known, the model does not have to choose a path every time. When new information changes the path, more freedom to act can help. That also leaves more possible paths to check.

That was why I separately addressed how much authority AI should have. Even if the model prepares the correct refund amount, permission to send the money back needs to be enforced separately. Human approval provides control only when the person can see the necessary information and change the decision before the action takes place.

Some of the customer support, quote, and refund scenarios in these articles are hypothetical. I do not present them as client projects I have carried out. I use them to show what information and responsibility different decisions require.

Looking back at older systems

These questions have counterparts in work that predates AI. In August, I wrote about the mystery shopping system I built at PlusValue. The story belongs to the period that began in 2005 and in which I was involved until 2008. Finding my former partner Galip's account of the early days prompted me to expand on a brief sentence on my About page.

The system connected applicants, assignments, field visits, form data, and reporting. The work extended beyond putting a form on a screen. Clients needed to see the collected information while the fieldwork was still under way. We tried to meet an expectation that seems ordinary today with the tools available then.

I did not want to embellish that history. I also wrote that we had not handled applicants' personal data with the maturity I would expect today. Saying “as far as I know, we did not lose data to an outside party” did not show that we had put sound data protection practices in place.

The bank transaction integration article approached the same question of responsibility through a more recent experience. We had set up the connections through a provider. Along with API access, we had handed over a significant part of the responsibility for maintaining connections to different banks. That choice also created a new trust boundary. In the August article, I explored the maintenance and trust implications of that earlier decision.

The work behind quickly generated code

My article about the cost of software verification opens with a developer bringing me a small application built with AI for a final check. The code was written and had been through an initial review. To approve it, I still needed to understand the problem it addressed, its assumptions, and how it behaved when something went wrong.

When the author cannot explain decisions in the code, the reviewer has to reconstruct them. As production gets faster, that work can quietly move onto someone else's desk. I also said in the article that I benefit from AI's speed in my own work. I wanted to explain where delivery still requires human effort while acknowledging the gain in speed.

I explored a similar issue when revisiting the archive. Rather than preserve my 2021 REST series unchanged, I carried its principles into checks for developing APIs with AI. Decisions about deletion, record ownership, permissions, and retries should not enter the code as unspoken assumptions. Sometimes keeping useful knowledge means changing how it is published.

Deciding what to keep in the archive

In August, I reviewed older articles on my site and removed some of them. In the content pruning case study, I explained why traffic figures alone could not make the decision. I might not want to update an installation guide that people still read. An article with no traffic might contain a real experience documented nowhere else.

I treated removal and consolidation differently. I took guides offline when I could not reliably keep them current and had no replacement article. I preserved the useful principles of the REST series in the new article and redirected the old URLs to it. I was trying to decide which knowledge was useful today and in what form, rather than erase my technical history.

I was not yet claiming that this decision had produced good SEO results. Would the removed pages drop out of the index? Would the remaining articles form a more coherent body of work? Would I have more time for the topics I wanted to maintain? Those were questions to follow.

In my article about AI visibility tools, I also considered the limits of measurement. A brand appearing in selected prompts is a different record from an actual customer seeing it. That was also why, when measuring success in the enterprise AI series, I distinguished an answer, a completed task, and a business effect.

Pruning the archive leaves fewer articles. Faster code production puts more code in front of us. In both cases, counting is easy. To see what is still correct, useful, and worth maintaining, we have to open the file and examine the work inside it.