September 2026: What I Wrote, and Why

In one of my first articles in September, I described finishing a job with AI in about an hour that I would otherwise have left undone. I had simplified PeşinTaksit's infrastructure. A small project I paid little attention to no longer needed four separate containers for me to manage.

That gain was easy to explain: the job was done, and I had less infrastructure to maintain. Our attempts to analyse sales calls with AI at work took more explaining. Before we could get useful results, we had to make explicit some things we had assumed the company already knew.

Looking back over September's articles, I can see the difference between those two scales of work. Some jobs were mine to decide on and finish. Others depended on bringing together data, responsibilities, and people's knowledge. My own working habits became part of the writing too.

Finishing a job I had put off on PeşinTaksit

PeşinTaksit's old setup worked. MariaDB, Redis, Fastify, and Nuxt all did their jobs. But the product's traffic and the attention I gave it did not justify the maintenance burden. I wanted to simplify it; I did not want to spend three to five days doing so.

In my account of moving PeşinTaksit to Cloudflare Workers with AI, I explained how that calculation changed. About an hour was the time I observed. Three to five days was my earlier estimate, never tested by doing the same job without AI. Comparing them does not establish a speed record. What mattered to me was that a job I would have put off was finished.

I later added the interface work to that article. The infrastructure was simpler, and the comparison screen had been reworked. I did not present a measurement showing that users were making better payment decisions.

I took the experience further in an article about reconsidering deferred work. Some jobs we once decided were not worth the effort may now be feasible. Updating an old estimate still means allowing for review and the work of making the transition. PeşinTaksit had not become more important to me. I could do more within the time I was willing to give it.

A sales-call transcript was not enough

Analysing sales calls seemed straightforward at first. We would give AI the conversations and ask it to evaluate them against our criteria. Understanding the circumstances of a call, however, required information from outside the conversation.

The CRM records had been written so that an employee could quickly get a sense of a customer. They were less suited to detailed analysis. Our instructions also failed to spell out enough of the exceptions managers took into account when assessing calls. We went back over the data, criteria, and prompts repeatedly.

I used that experience to write about the difference between building a tool and transforming a company. The time-consuming work was drawing out knowledge embedded in everyday judgments. Getting a manager to explain why they considered a call successful was not something the technical team could solve by writing code faster.

We had a concrete need in conversion rate optimisation, or CRO, too: instead of having someone watch Clarity session recordings one by one, we wanted AI to inspect them and find where visitors struggled. Investigating that request showed us that access to dashboard data and access to the recordings we wanted to study were different things.

When writing about what AI could take on in CRO research, I tried to keep that original workload in view. A polished report would not be enough. We wanted to spend less time reviewing recordings. Automating a different task would not deliver the same saving.

What happens to the knowledge inside a team?

Some of what a company knows is in its files. Some is in the reasoning behind people's decisions. The difficulty we encountered with sales calls also arises when employees change roles.

In my article on protecting organizational memory, I discussed why keeping experienced people in the company is not enough to keep their knowledge available. If someone moves to a new role and has no time for their old team, that knowledge can become harder to access without anyone leaving.

Other articles that month explored redesigning work, people's place in a process, and the capacity of smaller teams. As code and drafts become easier to produce, we need to see who ends up carrying the review and decision workload. The same assessment has to include the real work through which a newcomer will learn to make those decisions.

In my article on smaller teams, I also described my own experiment with Godot. I managed to build a basic 2D game with AI. My software experience helped. I cannot claim to know the games market or to have developed a commercial game. My own example showed me the distance between being able to start producing something and understanding the whole business around it.

I am waiting for water, not a reply

One of September's business articles began with my delayed water deliveries. Water I normally expect within two hours sometimes arrives two days later, and sometimes never arrives. I call the call centre. They say they have passed the matter to the local distributor. I keep waiting.

I used that experience to imagine an AI project: a system that answers my complaints instantly and automatically notifies the distributor. I am not saying the company actually uses such a system. In “Do We Need AI?”, I asked whether a faster reply would leave me with the same delivery problem.

The call centre's metrics might improve. We would still need to see what changed in the customer's day. That is also why I distinguish the easier maintenance of PeşinTaksit from the value it provides to users. A benefit for the person doing the work does not automatically mean a benefit for the person relying on it.

The same measurement problem appeared in another form in my articles about SEO and AI visibility. We still need to explain how a model's mention of a brand translates into that brand helping a customer. When I wrote about why getting AI to recommend our brand is the wrong starting goal, I wanted to keep content decisions connected to readers' needs.

Choosing a model also means defining its use

September's model-selection articles considered the work we take on as our options multiply. I discussed when one model might be enough and what running an open-weight model ourselves requires in separate articles. Adding models can add selection and review work. Hosting one ourselves means taking over some of the provider's responsibilities.

In my writing on the EU AI Act, I looked at why systems that seem similar can carry different responsibilities. Having the same model answer a question and help make a decision about a person are different uses. Those articles discuss why a company needs to describe clearly where and for what purpose it uses the model.

My working habits belong in this picture too

My article about English came from noticing that the things AI makes easier do not all have the same consequences for me. After changing jobs, I had less need to use English. Working with AI in Turkish had reduced another of the remaining opportunities to practise.

That led me to write about bringing English back into my working day. Rather than set up a separate study routine, I had started trying to do my existing work in English. I also asked my assistants to correct significant mistakes. That article did not report a result yet. It recorded what I wanted to change.

I wrote about how I prepare articles from two other perspectives. Working with my archive when writing with AI meant returning to what I had already said when an interesting source arrived, rather than immediately generating another draft. Sometimes an addition to an older article is enough. Sometimes the same idea does not need another article.

In my Open Publishing and monthly reporting experiment, I described how I try to make the decisions behind the numbers visible. I explained why I did not count an apparent record month as audience growth, why a report with sound analysis could still be hard to read, and how I changed my working rules in response. These were experiences I wrote about in September; some extended back into earlier months.

I also wrote separately about the “prepared with AI assistance” note beside my articles. That note alone does not explain who did what. Editing the language and turning someone's views and experience notes into a first draft are different ways of working. The explanation I give readers needs to match the work that actually happened.

With this monthly review, I want to show a little more of how the writing comes together. I want to connect the articles without retelling everything each one already covers. September also left some questions open: will practising English become a sustainable habit? Will returning to the archive help me make better decisions about what to write? And which changes that make my work easier will I be able to show have made other people's work easier too?