Unplanned Solutions, Permanent Tools
From Factory to Article: A User’s Field Report from the AI Ecosystem (Article 10)
Aydın Tiryaki & Claude Sonnet 4.6
1. Introduction
The history of engineering is full of examples of unplanned solutions becoming permanent tools. Unix’s pipe mechanism was born from a programmer’s immediate need. Post-it notes were the product of a failed adhesive experiment. Penicillin emerged from a laboratory accident.
Similar transformations occurred during the development of the Gem Factory. A forbidden tool became indispensable. A temporary solution became permanent architecture. An unexpected observation gave birth to a new method.
This article brings together the lessons learned in the field — from the emoji detector to the two-room architecture, from listening mode to the numbering system. Each lesson consists of a problem, the solution to that problem, and the logic behind the solution.
2. First Lesson: The Transformation of Emoji
2.1 The Beginning: A Forbidden Tool
In the early versions of the Gem Factory, emoji was strictly forbidden. The reasoning was clear: every emoji counts as two characters, is most likely processed as a separate token, and creates unnecessary load in Gem texts.
The rule was explicit. No emoji would enter the Factory text.
2.2 The Problem: Contamination and Version Detection
As production deepened, a new requirement emerged. The Gem Factory was updated. A new version was created. But had this new version actually been transferred to the active Gem? Was the Factory’s dominant persona layer attempting to leak in?
Answering these questions required searching for clues within the text. But the text was long, complex, and filled with similar sections. Scanning by eye was both exhausting and prone to error.
2.3 The Solution: A Visual Signal
The solution appeared on its own: emoji could be used as a visual signal.
A specific emoji was chosen for each Factory version. When moving to a new version, the emoji was changed — a different color, a different form. Now the following questions could be answered with a single glance: Is this Gem running on the correct version? Did the version transfer occur? Has the Factory leaked in?
The forbidden tool became an indispensable detector.
2.4 Its Counterpart in the Software World
The name for this solution in the software world is “canary value.” A marker value that shows instantly whether a system is operating correctly. Inspired by the canaries used in coal mines, this concept took the form of emoji in AI Gem development.
3. Second Lesson: The Two-Room Architecture
3.1 The Beginning: The Limit of Content Rules
Following the May 19th rupture, the Factory encountered a serious problem: all outputs were being overwritten with copies of the Factory itself. Dozens of content rules were tried. None worked.
During the diagnostic phase, a critical conceptual distinction was made: this was not a content problem. It was a container problem. Container problems cannot be solved with content rules.
3.2 The Solution: Physical Separation
The solution came from accepting the scope of the problem: if the Factory is present in the context, it will leak. Therefore, physically separate the Factory from the production environment.
Two rooms were born: the Workshop and the Casting Room. The Factory runs only in the Workshop. Final outputs are pasted into the Casting Room — a Gem-free, blank window. The Factory is not present there. There is nothing left to leak.
3.3 The General Principle
The general principle behind this solution is this: if a problem cannot be solved at the content level, it must be solved at the structural level.
Content rules are powerful tools. But some problems are about where content is located — not what it says. The solution to such problems is not to change the content but to change its location.
4. Third Lesson: Listening Mode
4.1 The Beginning: An Impatient Platform
A recurring problem emerged in long development sessions: while the user was still conveying information, the platform assumed “there is enough information” and began producing output.
This was both a waste of quota and an interruption of context. The user still had things to say, yet the platform was producing output. And this output, produced with incomplete information, was most often inadequate.
4.2 The Solution: Periodic Reminder
The solution was simple: the instruction “we are in listening mode, do not produce” was given. But in long sessions, this instruction became buried in the depths of the context. The platform gradually forgot it.
The new solution: periodic reminders. Throughout the session, at regular intervals, the reminder “we are still in listening mode” was given.
This solution revealed: some instructions are not one-time but must be continuously refreshed. As the context grows longer, instructions given early lose priority. Periodic reminders compensate for this loss.
4.3 The General Principle
Giving an instruction is not sufficient. Ensuring that the instruction remains effective is also the user’s responsibility.
This resembles a “heartbeat” mechanism in software: regularly verifying that a connection is alive. The listening mode reminder is a heartbeat that verifies the context remains active.
5. Fourth Lesson: The Necessity of the Numbering System
5.1 The Beginning: Platform Resistance
The hierarchical numbering system — section numbers, sub-numbers, cross-references — was from the outset a preference that had to be defended against the platform.
Gemini showed resistance. ChatGPT did not use it without being pressed. Claude also preferred to write without numbers when left to its own devices.
Why? Because platforms are trained to produce fluid, natural language. Numbers interrupt this flow.
5.2 The Source of Necessity
The indispensability of the numbering system was proven during the refactoring process.
“Modify that paragraph” is ambiguous. “Modify section 8.1.3” is precise. The Patch Workshop knows exactly what is to be changed. The user can track exactly what has changed.
A system without numbers is a system that cannot be addressed. A system that cannot be addressed is a system that cannot be controlled.
5.3 The General Principle
Managing complexity requires addressability. Every component of a system must be clearly defined and referenceable.
This principle has been one of the cornerstones of software engineering since the 1970s. It applies equally in AI Gem development.
6. Fifth Lesson: Modularity
6.1 The Beginning: The Limit of a Monolithic Structure
The Gem Factory was initially gathered into a single structure. Every feature, every rule, every protocol in the same text. Complete, comprehensive, unified.
But as it grew, problems began. The context filled. Priorities drifted. Inconsistencies multiplied.
6.2 The Solution: Division into Workshops
The solution was to apply a principle software engineering has known for decades: modularize.
Factory core, patch workshop, full text workshop, output workshop. Each specialized in its own domain. The factory core coordinated; the workshops produced.
6.3 The General Principle
A system cannot be larger than it can operate efficiently. When it grows too large, it must be divided. Division is not a loss of capability — it is structural maturation.
This principle applies to the Factory. It applies to Gems. And it most likely applies to AI models themselves — no matter how large the context window, every system has an efficiency threshold.
7. Sixth Lesson: Real Testing, Not Hypothetical Testing
7.1 The Beginning: The Testing Requirement
Every time the Factory was updated, it needed to be tested. But how?
Hypothetical testing — “can you do this task?” — was insufficient. It did not reflect real production conditions.
7.2 The Solution: A Testing Ecosystem of Sixty Gems
The solution was to build a real testing ecosystem of over sixty Gems. Different lengths, different structures, different functions. Every new Factory version was tested in this ecosystem.
This was the adaptation of regression testing from the software world to the natural language environment.
7.3 The General Principle
Real systems must be tested under real conditions. Hypothetical testing does not provide confidence. A solution that has not been tested in the field is not a solution — it is a hypothesis.
8. The Common Denominator of the Lessons
These six lessons were born from different problems, in different contexts. But they all share a common denominator: each required first experiencing the problem, then finding the solution, then transforming the solution into a principle.
None was designed at a desk. All were learned in the field.
And this way of learning is the essence of working with AI platforms. Platforms do not explain everything in their documentation. Some limits only become visible under production pressure. Some solutions only emerge when those limits are confronted.
Learning in the field is not a methodological deficiency — it is a methodological richness.
9. Conclusion
Emoji became a debugging tool. Two rooms solved a production crisis. Listening mode prevented quota waste. Numbering made complexity manageable. Modularity kept the system alive. Real testing built confidence.
None of these were written in any manual. All were learned in a real production environment, through confrontation with real problems.
Lessons learned in the field are more robust than those designed in the laboratory. Because the field must pass examinations that theory cannot.
Aydın Tiryaki & Claude Sonnet 4.6 June 2026
| 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 ░ |░Fabrikadan Makaleye: Yapay Zeka Ekosisteminde Bir Kullanıcının Saha Raporu │From Factory to Article: A User’s Field Report from the AI Ecosystem ░ 07.06.2026
Aydın Tiryaki 