As the author of "Electronic Lyre" (Электронная лира), I want to share why this book is essential reading for developers working at the intersection of code and creativity. For years, we've treated poetry generation as a side project – a fun way to test RNNs or transformers. But when I started training models on Russian poets like Mandelstam and Pasternak, I realized we're not just building "poetry machines." We're building statistical mirrors of style itself. The book dives into how moving from combinatorial text shuffling (the 20th-century approach) to predictive neural networks didn't just change the output quality; it changed what the machine is actually doing. It's no longer playing dice with words; it's learning the fingerprint of a poet's syntax, rhythm, and even their typical errors.
From an engineering perspective, the most fascinating part was running the experiments that blurred the line between human and machine writing. I used LSTM-based models trained character-by-character and, later, ruGPT transformers. The goal wasn't to pass the Turing test – that's boring for both coders and poets. Instead, I asked a critical question: can a professional philologist interpret a poem generated by a neural network as a meaningful text? The results were paradoxical. Statistically, the generated texts were often more like the original author than the author's own poems (when tested with methods like Burrows's Delta). To a human reader, however, they felt broken, uncanny – like a face in the "uncanny valley." But it's precisely this imperfection, these "glitches" in the statistical distribution, that create new, unexpected poetic images. It taught me that our code, when it fails gracefully, can produce something more creatively interesting than when it succeeds perfectly.
This book isn't a manual, but it's a field guide for navigating the literary landscape we've helped build. It tackles the hard questions we often avoid: can we ever truly own the output of a model? Will we be replaced? My argument is that because a machine generates text without effort or personal cost, its product will never hold the same value as human work – just as a printed book didn't make manuscripts worthless. The real future isn't replacement, but augmentation: using the AI as a prosthetic for exploring style, creating "neural readings" of poetic epochs. If you're a developer who works with language models, this book will challenge you to think about your code not as a tool that produces text, but as a participant in a very old conversation about what it means to write and read.
Let me expand on why this matters for developers and what you'll actually find inside.
When I started this project, I wasn't interested in another "AI writes poetry" demo. We've all seen those. Instead, I wanted to understand what neural networks reveal about the structure of poetic language when we train them not on generic text but on specific, stylistically dense corpora. The technical core of the book is built around two distinct approaches: first, the old-school combinatorial methods (random word selection from a thesaurus with metrical constraints), and second, the modern LSTM and transformer architectures that learn patterns at the character and word level. I walk through the actual training process – from the first chaotic epoch where the model outputs nothing but random Cyrillic letters, to the moment when it begins to grasp morphological patterns like "-ение" or "-ость", to the astonishing point where it can generate grammatically correct but semantically broken lines that somehow feel like Russian poetry. This isn't magic; it's statistics applied to sequences, but the emergent properties are genuinely surprising.
One experiment I describe in detail is particularly revealing for developers working on generative models. I trained a network on the complete poetic works of Nekrasov and then generated hundreds of new four-line stanzas. Then I asked professional philologists – people who literally memorize poetry for a living – to identify which fragments were original and which were synthetic. The results were counterintuitive: when I used high "temperature" settings to encourage creativity, the experts could often tell something was wrong, but they couldn't agree on what was wrong. The generated texts had the right vocabulary distribution, the right rhythm patterns (mostly iambic), and even the right thematic clusters (peasants, suffering, Russian landscapes). Yet the texts felt "off" – like a voice that sounds familiar but isn't quite your friend's. The statistical methods, however, told a different story: Burrows's Delta, a standard authorship attribution algorithm, consistently misclassified the generated texts as more typical of Nekrasov than Nekrasov's own poems. The machine had become a statistical caricature of the author, amplifying his most frequent patterns while missing the rare, surprising choices that make human poetry human.
This leads to a deeper point about what our models actually learn. We often talk about "understanding" in AI, but what we really have is pattern compression. A neural network trained on a poet's work doesn't understand love, death, or winter; it understands that certain words (like stikhotvorenie for poem, niy for grief, or nebo for sky) co-occur with certain others in predictable ratios. It has no lived experience of weather or emotion. Yet, and this is the crux of the book, that doesn't make its output meaningless. Meaning, I argue, is not intrinsic to the text; it's constructed by the reader. When I read a generated line like "Ветер знакомый ребенком" (The wind familiar like a child), my brain desperately tries to find coherence. I supply the missing context, the emotional weight, the possible backstory. The machine didn't intend that meaning, but I, as a reader, created it. This is exactly what happens when we read human poetry too – we just forget that we're doing it. The difference is that with human authors, we can point to a conscious mind that might have intended something similar. With AI, we have no such anchor, so we're forced to confront our own role in the meaning-making process.
From a developer's perspective, this raises practical and ethical questions. When we deploy a language model for creative writing, are we building a tool, a collaborator, or a substitute? I argue for the "collaborator" model. The book explores the concept of "computational creativity" and shows how developers can use generative models not to replace writers but to act as "idea generators" or "style explorers." For example, if you're designing a writing assistant, you could use a model to suggest unexpected word combinations based on the statistical style of a particular author, rather than just the most probable next token. This moves beyond autocomplete into creative inspiration. I also discuss the legal and philosophical issues: if a model generates a commercial poem, who owns it? My argument is that because the machine has no conscious intent and exerts no effort, the creator is not the algorithm but the human who selects, curates, and contextualizes its output – just as Marcel Duchamp claimed ownership of his readymade urinal not because he made it, but because he presented it as art.
Another theme I delve into is the historical continuity between AI poetry and earlier avant-garde movements. The combinatorial approach of the 1960s (randomly recombining words from a dictionary) was not a technological necessity but a cultural one. It was part of a broader artistic protest against rationalism and control – a legacy of Dada and surrealism. When I write code that shuffles words, I'm unknowingly continuing a century-long conversation about randomness and creativity. This is something developers often miss when we focus solely on metrics like BLEU scores or perplexity. The book connects the dots between early experiments like the "Muses" of the 1950s, the Soviet "Skol" programs of the 1980s, and today's GPT-based systems. It shows that each generation of poets and programmers has used the tools available to question what art is and who gets to make it. That historical perspective, I hope, will help developers think more critically about the social and cultural implications of their code.
For the more technically inclined, I include a chapter on the architecture of the models I used, including specific hyperparameters, training data preparation, and the challenges of generating verse in a highly inflected language like Russian. I also share code snippets and practical lessons learned: why character-level training initially fails but eventually captures morphological nuances, why temperature sampling is a crude but effective control for creativity, and why transformers, despite their advantages, still struggle with narrative coherence beyond a few lines. The book isn't a tutorial, but it provides enough detail for a skilled developer to reproduce the experiments and adapt them to other languages and literatures.
Finally, I want to stress that this book is written for a specific audience: developers who are curious about the humanities, and humanists who want to understand code. It's intentionally low on math and high on metaphor. I explain backpropagation and attention mechanisms through analogies to reading and interpretation. The goal is to create a conversation, not a technical manual. If you're a coder, you'll find familiar concepts presented in an unfamiliar light. If you're a poet, you'll see your craft through the lens of statistics and probability. And if you're both – or aspiring to be – I believe you'll find this book a valuable companion in navigating the emerging landscape where software and literature increasingly overlap.
I hope you'll pick it up and join the discussion.
Publisher's Page: https://eupress.ru/books/index/item/id/480