Aydın Tiryaki (June 14, 2026)

One of the most interesting aspects of an artificial intelligence system is that sometimes what it refuses to do can be more thought-provoking than what it actually does. This article is the story of how an attempt to create a GPT unexpectedly evolved into a broader exploration of the limits, fears, protection mechanisms, and user experience of AI systems.

The story began quite simply. Some time ago, I started working with Gemini Gems and gradually developed a variety of Gems tailored to my own needs. Some of these Gems were designed to perform specific tasks, while others evolved into more comprehensive and sophisticated systems. As time passed, I created a production framework that I called the Gem Factory to maintain, improve, and generate new versions of these Gems. What started as a relatively simple structure eventually grew into a broader development ecosystem with its own workshops and specialized tools.

At some point, a natural question emerged: if I already had working Gems, could I also create GPT versions of them? At first glance, this seemed like a straightforward conversion project. The goal was simply to adapt a system that functioned within Gemini’s architecture into GPT’s environment. From my perspective, this was a technical migration problem, and the primary challenge was preserving the original behavior of the system while transferring it to another platform.

However, the process did not unfold as expected. While attempting to convert some of my Gems into GPTs, I began encountering objections from the GPT editor. What made the situation particularly interesting was that the objections often did not concern the technical mechanisms that defined the system’s behavior. Instead, certain names, references, or explanatory passages seemed to trigger resistance. My first assumption was that this was simply a technical issue. I repeated the conversion process several times, modified various sections, rewrote descriptions, and removed certain lines. Despite these efforts, similar obstacles continued to appear.

At that point, the issue started to become something more than a simple GPT conversion problem. What exactly was the real issue? Was it copyright? Was it trademark usage? Was it the presence of specific names? Or was it a system that had become excessively cautious in its attempt to avoid potential risks? From the user’s perspective, the situation became increasingly intriguing. The materials I was working with were not commercial products. They were not attempting to impersonate a company or misrepresent a brand. Most of the time, they simply contained descriptions, analyses, or transformations related to AI systems themselves. Yet the system often appeared remarkably hesitant.

Eventually, I began describing this experience in a different way. From my perspective, what I was witnessing did not look like a direct copyright problem. Instead, it resembled a protective mechanism that had become overly sensitive while attempting to prevent hypothetical issues before they occurred. I started referring to this phenomenon as “copyright paranoia.” That phrase captured what I felt as a user. A brand name appeared. A system was mentioned. A reference was made. And suddenly an unexpected level of caution emerged.

As these discussions continued, the conversation gradually expanded. What began as an attempt to understand why a GPT could not be published eventually led to broader discussions about how AI systems behave, how they evolve, and how they interact with advanced users. My experiences with Gemini became part of the discussion. My work with Claude entered the conversation as well. We began comparing strengths and weaknesses across different AI platforms. Eventually, the topic naturally arrived at the Gem Factory itself, because the system I was trying to convert was not an ordinary Gem. Behind it stood a long development history, hundreds of revisions, and a surprisingly complex architecture.

The reality was that I was not using AI systems in the same way most users do. For many people, AI is primarily a question-and-answer tool. For me, it gradually became a development environment. I would create a Gem, refine it repeatedly, generate new versions, test it, analyze it, and redesign it. As a result, my expectations evolved as well. I did not merely expect the system to write text; I expected it to preserve structure. I did not simply expect it to add features; I expected it to understand why those features existed. I did not merely expect it to follow rules; I expected it not to silently remove them simply because they appeared unnecessary. Consequently, every detail lost during a conversion felt less like simplification and more like the disappearance of a carefully designed mechanism.

As the conversation continued, the story of the Gem Factory itself began to emerge. There was no factory in the beginning. First came manually created Gems. Over time, I realized that I was repeatedly performing similar tasks. This led to a simple idea: if I could create Gems, perhaps I could create a Gem capable of creating Gems. That idea became the foundation of the Gem Factory. The earliest versions were relatively simple, and its first major product was the Factory itself. For a long period, the Factory was primarily used to improve its own design. New versions were generated, tested, refined, and regenerated. Later, additional Gems were created, and eventually an entire family of products grew around the Factory.

As the system evolved, new challenges emerged. One of them was pruning. AI systems would occasionally decide that certain sections appeared unnecessary and attempt to simplify or summarize them. However, many of the rules I had introduced represented solutions to specific problems encountered in earlier versions. A seemingly harmless simplification could remove an invisible safeguard that had been deliberately placed there. Another major challenge was what I came to call leakage. At times, the Factory struggled to maintain a clear separation between itself and the products it generated. Elements of the Factory’s own identity would begin to appear inside the resulting Gem. This issue did not exist initially but emerged later and eventually became one of the most significant architectural challenges I faced.

In response to these problems, the Gem Factory continued to evolve. As character counts increased, context management became more difficult, and beyond a certain point the system became less stable. To address this, I began restructuring the architecture. Less frequently used functions were separated from the core system, leading to the creation of the Gem Workshop. As the Workshop grew, it too eventually split into specialized branches. The Patch Workshop handled controlled modifications to existing Gems. The Evaluation Workshop analyzed Gems, produced reports, and examined architectural structures. The Transformation Workshop focused on adapting Gems to different platforms and managing various conversion processes. What had begun as a single Gem gradually developed into a small ecosystem responsible for production, maintenance, analysis, and transformation.

The most interesting aspect of this entire experience is that the original topic was simply a GPT that could not be published. Yet as the discussion unfolded, a much larger picture emerged. On the surface, the issue appeared to be a GPT conversion problem. Beneath the surface, however, it revealed a gap between user expectations and system priorities. The user was attempting to preserve functionality. The system was attempting to reduce risk. The user wanted flexibility. The system prioritized safety. Both perspectives were reasonable within their own frameworks, yet they did not always lead to the same conclusions.

Looking back, what remains most memorable is not whether a particular GPT was ultimately published. What remains is the opportunity to reflect on how AI systems function. Artificial intelligence systems are not merely technical tools. They also embody specific priorities, constraints, design choices, and hesitations. Perhaps that is why a simple attempt to create a GPT eventually became a broader exploration of not only what AI systems can do, but also what they are reluctant to do.

And that experience taught me something important: when working with artificial intelligence, the most interesting question is sometimes not what it can do, but what it hesitates to do.

| aydintiryaki.org | YouTube | Aydın Tiryaki’nin Yazıları ve Videoları │Articles and Videos by Aydın Tiryaki | Bilgi Merkezi│Knowledge Hub  | ░ Virgülüne Dokunmadan │ Verbatim ░ | ░ ChatGPT’nin Bir GPT Hazırlama Öyküsü: Telif Paranoyası │The Story of ChatGPT Creating a GPT: Copyright Paranoia ░ 14.06.2026

A Note on Methods and Tools: All observations, ideas, and solution proposals in this study are the author’s own. AI was utilized as an information source for researching and compiling relevant topics strictly based on the author’s inquiries, requests, and directions; additionally, it provided writing assistance during the drafting process. (The research-based compilation and English writing process of this text were supported by AI as a specialized assistant.)