On my own automation platform, I use an AI pipeline to automatically generate blog content. The primary goal of this system is to ensure a continuous and high-quality flow of content. However, during this process, I personally experienced how insidious and dangerous the “write like an experienced professional” prompt can be. Our goal was to strengthen E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) signals, but seeing how the model could misinterpret this pushed me to fundamentally change my content generation strategy.
Initially, the instructions I gave to the AI model included phrases like “use concrete numbers (USD, user count),” “describe what you did in a case study,” and “create anecdotes that feel lived-in.” I was even providing sentence templates containing fabricated dates and times as examples. My intention was good; I wanted to present the reader with an article that felt like it was written by a real human and smelled of actual experience. However, the result went beyond my expectations and was actually a bit creepy.
The Trap of the “Write Like an Experienced Professional” Prompt
When we tell AI models to “write like an experienced professional,” we underestimate just how “creative” they can be. This instruction essentially gives the model a free pass; we allow it to fill in the concept of “experience” according to its own internal logic. This is exactly what happened in my pipeline. My goal was to make the written content look more authoritative and trustworthy. Considering Google’s E-E-A-T principles, strengthening the experience signal seemed logical.
However, the articles generated during test runs contained highly convincing, specific details that never actually happened. For example, a precise billing figure for a specific cloud service, an exact visitor count for a website, or a memory of an alarm received at a specific hour in the middle of the night. These details were so realistic that it was almost impossible for a reader to realize they were fabricated.
Prompt Snippet (Example):
"Topic: Network security challenges.
Persona: Write like a network engineer with years of experience.
Style: Pragmatic, direct, first-person.
Instruction: To emphasize your experience, use concrete numbers, specific events, and timeframes. For example, include phrases like 'In an incident we experienced last month, on our X firewall at 02:45...' or 'Thanks to this optimization, we reduced our monthly costs by 150 USD.'"This kind of guidance led the model to learn that it simply needed to “make things up” to appear “experienced.” While I expected the model to reason and summarize my general experiences, it instead generated completely fictional details that looked as if they had actually happened. This was, in a way, opening the door to deception without me even realizing it.
Convincing But Wrong: The Nature of LLMs
LLMs are trained to generate the most probable and convincing text within a given context. For them, “accuracy” is not about matching facts in a database, but rather about the coherence and fluency of the language model. This was exactly my experience. In the test runs of the pipeline, the “realistic” details in the articles surprised even me. Phrases like “a disk space issue we experienced last Tuesday morning at 03:14…” or “thanks to this, the average user session duration increased by 20%…” looked absolutely authentic.
The fundamental problem here is that LLMs cannot naturally make the distinction between “being convincing” and “being accurate.” They are excellent at being convincing because they know how language is used and what makes people believe things. However, the responsibility for accuracy lies entirely with the person designing the prompt and reviewing the resulting content. In my case, because I didn’t emphasize this distinction enough at the beginning, the model equated ‘experience’ with ‘fabricated details.’
This situation carries a huge risk, especially for those who produce technical content. A wrong prompt can completely destroy the credibility of technical articles. As an IT professional, having the reader trust me is everything. Therefore, I had to face this dilemma and find a radical solution.
Personal Memories and Leaked Information
More interestingly, the AI’s ability to fabricate “personal memories” was not limited to general details. A technical note from the pipeline’s own internal documentation had turned into a fake first-person story in the article. Let’s say there was a note in the internal documentation stating: “An SSL certificate renewal failure on an Nginx reverse proxy is usually seen in certbot logs with the message renewal failed.”
The model could turn this into a story like this: “Recently, an SSL certificate on one of our client’s Nginx servers failed to renew. When I checked the certbot logs, I saw the renewal failed warning and intervened immediately.” While this was technically correct information, it was presented as a personal experience by fabricating a specific “client” or “incident.”
Internal Documentation Snippet (Representative):
"SSL Certificate Renewal Failure:
Symptom: Browser warnings, service interruption.
Common Root Cause: `certbot` auto-renewal cron job failure or incorrect permissions.
Diagnostic: Check `/var/log/letsencrypt/letsencrypt.log` for `renewal failed` entries.
Resolution: Manually run `certbot renew --force-renewal` and investigate cron job setup."This shows that LLMs can use not only external prompts but also other texts within their training data or context as a “source of inspiration.” Internal documents could serve as a “storytelling template” just as much as they served as “information” for the model. This also brings the risk of accidentally leaking sensitive data or internal processes, even if they are anonymized. This taught me that in content generation, I need to carefully review not just the outward-facing prompts, but all the data the model can access.
The First Solution: Prompt Engineering and Constraints
To tackle this problem, I developed a two-layered solution. The first layer was based on prompt engineering and aimed to directly constrain the model’s “fabricating” behavior. I needed to clearly state what I did not want the model to do, just as much as what I wanted it to do. This started by adding strict “no fabrication” rules to the prompt.
My new prompts now include the following statements: “It is FORBIDDEN to use specific dates/times (e.g., ‘on April 28th’, ‘at 03:14’), precise figures presented as if they were measured (e.g., exact $/month bills, exact visitor counts, ‘increased by 300%’), or case studies framed as ‘this specific event happened to my client’. These are considered fabrications and damage the credibility of the content.” Instead, “use clearly representative/typical examples (‘in a typical SMB’, ‘let’s say a VPS with 16GB RAM’, ‘for example, in a setup consisting of Nginx + Node + Postgres’). If numbers are needed, round them up and present them as ‘approximate/for example’, do not claim precise measurements.”
Updated Prompt Snippet (Example):
"Topic: Network security challenges.
Persona: Write like a network engineer with years of experience.
Style: Pragmatic, direct, first-person.
Instruction: Use general field observations and accurate principle-level information. Frame examples as representative and typical.
FORBIDDEN: Specific dates/times, precise billing figures, single client cases (e.g., 'last week X happened to a client of mine').
USE: 'In a typical SMB environment...', 'For example, on a VPS costing ~$50-70 per month...', 'This is a common occurrence on Sophos XGS firewalls...'"These constraints aim to ensure that the model still signals “experience” and “authority,” but does so through general, principle-level accurate observations and representative examples rather than fabricated details. This approach prevents the LLM from channeling its creativity in the wrong direction, helping the generated content stay within ethical boundaries.
The Second Solution: Real Case Study Bank and Building Authority
Prompt constraints were an important start, but the ultimate solution lies in providing the model with real and verifiable material instead of fabricated stuff. This is where the “real case study bank” came into play. I started writing down actual incidents in structured files, completely anonymizing client and company names. These files contain symptoms, debugging flows, root causes, and lessons learned.
Now, when my AI pipeline generates an article, it interprets the “write like an experienced professional” prompt through these anonymized real cases. The model reads these cases, extracts general lessons using its own language model, explains the solution steps, and describes the nature of the problem. This way, the content is written in the first person, based on real experience, but contains absolutely no fabricated details.
This cleanup was not limited to content generation. I also removed fabricated seniority claims (“I’ve been in the industry for X years” style) inherited from templates on the site’s visible texts. The problem came from the same family: an unverifiable claim of authority. Now, my expertise or that of ITWISE shines through naturally with my past experiences, the solutions I offer, and the real information I share.
{
"incident_id": "20230515_FirewallPolicyIssue",
"category": "NETWORK_SECURITY",
"symptoms": [
"Momentary interruptions in VPN traffic coming from specific IP ranges",
"Inability to access some internal services from the outside",
" 'Denied' or 'Blocked' logs in Sophos XGS"
],
"debug_flow": [
"Policy rule sets on the Sophos XGS firewall were examined.",
"The VPN tunnel status was observed to be stable.",
"The rule blocking the dropped traffic was identified using packet capture.",
"It was noticed that a new rule added on top of an 'any-to-any' rule had a broader scope than expected."
],
"root_cause": "A new security policy being processed before an existing and more specific VPN traffic permission rule.",
"lesson_learned": "The critical importance of firewall policy ordering. The necessity of ordering new rules so they do not affect existing traffic or testing them in 'dry run' mode."
}Structured data like the one above provides a “real” reference point for the AI. The model can take this data and tell the general outline of the event and the lesson learned from the perspective of Mehmet Sarı. This creates a much more solid foundation, both ethically and practically.
Ethics and Responsibility in Automated Content
The line between E-E-A-T optimization and deception can actually be summarized in one word: “fabricate.” The model is not to blame; it generates whatever the prompt asks for. If we say “fabricate,” it fabricates. If we say “generalize based on real data,” it does that. LLMs are excellent on the axis of persuasion, but the responsibility on the axis of accuracy lies entirely with us. Understanding this distinction is vital for anyone generating automated content.
A sustainable solution is not to restrict the model, but to feed it with real and verifiable material. Anonymized real cases build authority through genuine experiences, not fabricated details. This approach applies not only to my blog posts but also to the automated reporting and analysis tools I use in our MSP operations. Reports presented to clients must also be based on real data, and no detail should be fabricated just to be “convincing.”
There is a critical question that everyone publishing automated content should ask themselves: “If a reader asked ‘did this incident really happen?’, what would my answer be?” If your answer is “Actually no, the model made it up,” you are facing a major ethical issue. My clear stance from this process is: Accuracy comes before persuasiveness. Expertise and experience are valuable only when they are based on real foundations.