On 14 October 2025 I spent the evening at ING in Amsterdam for an AI meetup with two talks: one on how AI agents could talk to each other, and âHacking the Authoring Process: Lessons from Writing a Book with AIâ by Pini Reznik, CEO of re:cinq. This is a throwback post built from my photos of the slides. Where a slide didnât name a speaker, I donât either.
I write technical books myself, so this post ends with my take as an author.
At ING after the talks, under the lion and the line âEmpowering people to stay a step ahead in life and in business.â
Opening talk: how will AI agents talk to each other?
The first speaker presented under the Saptha.me name. The title slide, dated â14th Oct, 2025â, asked the question for the evening: âHow will AI agents talk to each other, share common memory, and even interact with agents behind paywalls and security layers?â A browser tab on the shared screen pointed to a GitHub project called Bindu, described as turning âyour agent into a living serverâ. The repository now lives at GetBindu/Bindu.
Early on, a slide said âLets Define First what is Agent?â, and the talk then made the case in both directions. A âSuccess Stories of Agentsâ slide showed METRâs chart, âThe length of tasks AI can do is doubling every 7 monthsâ, next to an article headlined âA new Mooreâs Law for AI agentsâ: in 2022 ChatGPT could do 30-second coding tasks, and today agents can autonomously do coding tasks that take humans two hours. The next slide was the counterweight: a Hacker News thread asking âAre there any real examples of AI agents doing work?â, a headline about fears of an AI bubble in Silicon Valley, and one about Deloitte being caught using AI in a $290,000 report for the Australian government âafter a researcher flagged hallucinationsâ.
The opening talk: the agent-communication question, and the ânew Mooreâs Lawâ slide.
Hallucinations in a published report made a natural bridge to the second talk.
Hacking the Authoring Process
Pini Reznik opening âHacking the Authoring Process: Lessons from Writing a Book with AIâ.
The structure of the talk was on the slide that followed: âStory in 17 Prompts + Patternsâ. Instead of a theory of AI-assisted writing, it walked through the actual prompts used along the way, and for each one, the pattern that came out of it.
The prompt on that slide was deliberately small: âTell me about design patterns in less than 30 words. History and description.â The answer shown was a clean, correct one-liner: design patterns originated in architecture and are âproven, reusable solutions to common problemsâ that âact as templates for solving issues within a specific design contextâ. The choice of example is no accident. A patterns vocabulary runs through the talk, from the title of this slide to the âantipatternsâ further on.
âStory in 17 Prompts + Patternsâ: the first prompt, and the kind of short answer a model gets right.
Prompt #4: the hallucination nightmare
By prompt number four, the tone changed. The slide was titled âPrompt #4 â The Hallucination Nightmareâ, and the prompt on it read: âYour last draft cited three experts who donât exist and a software library that was never released. Fix it.â
Underneath, under âAntipatterns Encounteredâ, the slide named the problem and the answer:
- Ungrounded Build-Up: âBuilding on unchecked claims is the cardinal sin of AI writing.â
- The Fix: âDevelop the Evidence Ledger pattern.â
The slide gives only the name of the pattern, but the idea is clear from the problem it fixes: if each draft builds on the claims of the previous one, a single invented expert or library spreads through every chapter that follows. The fix has to sit in the process, not in a better prompt.
Prompt #4: invented experts, a library that was never released, and the Evidence Ledger pattern as the fix.
The book: From Cloud Native to AI Native
The closing slide showed the book behind the talk: From Cloud Native to AI Native: Catching the Next Wave of Innovation, âAvailable now on Amazonâ, with the line âToday: 20 free copiesâ. Later in the evening, a name wheel came up on the screen for the draw.
The closing slide on both screens: the book, available on Amazon, and 20 free copies on the night.
re:cinqâs book page names Pini Reznik and Michael MĂźller as the authors and describes it as a 422-page book with â119 named patterns, pitfalls, and anti-patternsâ, accompanied by Pattern Cards for team workshops, and offers the full edition as a free download for a limited time. The patterns vocabulary from the talk is all over the bookâs description too.
The cover of From Cloud Native to AI Native: Catching the Next Wave of Innovation.
My take, as a technical author
I have written technical books on Ansible, Kubernetes and Red Hat Enterprise Linux with Apress and BPB, among them Ansible for VMware by Examples, Ansible for Kubernetes by Example and Kubernetes Recipes, co-written with Grzegorz Stencel. Four days before this meetup I gave my own talk on the craft, âHow to Write a Technical Book and Sell Worldwideâ at FikaWorks Day 2025: finding a topic, pitching publishers, structuring a manuscript, and working with technical reviewers and editors. Seeing the same process through the lens of AI made a good counterpart.
The Hallucination Nightmare slide is the one that matched my view of technical writing most closely. In a technical book, every claim, command and library name is something a reader will try. That is why my books are built on real-world examples and tested code. A tested example is evidence the text can stand on. A model that invents three experts and a library breaks exactly that contract. Ungrounded Build-Up is also why a separate, human review step still matters. A model that generated the claim is not the right tool to verify it on its own.
The pattern framing also resonates. In The Recipe Mindset I describe a recipe as a reusable decision: âfor this kind of problem, here is the approved pathâ. âStory in 17 Prompts + Patternsâ applies the same idea to the writing process. The prompts are one-off. The patterns are what a second author can reuse. My view is that this is the right way to treat AI in authoring: not as a ghostwriter, but as a component in a process with explicit checks, the same way we treat it in context engineering for production systems.
