DEV Community: Mykyta Chernenko

I Built an AI Pipeline for Books, Here's the Architecture

Mykyta Chernenko — Sun, 22 Feb 2026 21:52:13 +0000

We Treated Book Generation as a Compiler Pipeline. Here's What We Learned From 50K Books.

Most AI writing tools are chat wrappers. Paste a prompt, get text, copy into Google Docs, repeat. For a full book that's hundreds of round trips, and you lose all context between them.

I've spent 3 years in the AI + publishing space. Published books myself, built a reading platform (NanoReads, 130+ books, 341K readers), talked to hundreds of authors. The same complaints kept coming up: AI loses track of what happened 10 chapters ago, every chapter sounds different, dialogue is flat, and the output is full of "Moreover," and "Furthermore," and "It's worth noting that."

These aren't model quality problems. After generating 50K+ books on our platform (AIWriteBook), we're pretty confident the bottleneck is the specification pipeline, not the language model.

The architecture

We treat book creation as a multi-stage compilation pipeline:

Book Metadata -> Character Graph -> Chapter Outlines -> Chapter Content
     |               |                  |                  |
  (schema)       (schema)           (schema)          (streaming)

Each stage produces schema-constrained structured output that feeds the next stage. Nothing is freeform until the final prose generation.

Stage 1: Book metadata

User provides title + description. AI generates structured details:

{
  "title": "The Dragon's Reluctant Mate",
  "genres": ["Fantasy", "Romance"],
  "tone": ["dark", "romantic", "suspenseful"],
  "style": ["dialogue-heavy", "fast-paced"],
  "target_audience": "Adult fantasy romance readers",
  "plot_techniques": ["enemies-to-lovers", "slow-burn", "foreshadowing"],
  "writing_style": "..."
}

Everything downstream uses this as context. Tone, style, audience are constraints, not suggestions.

Stage 2: Character graph

Each character is a structured node with voice, motivation, arc, internal conflict. The important bit: when generating a chapter, we only pass the characters present in that chapter. The model gets their specific voice patterns, current arc position, relationship dynamics with the other characters in the scene.

{
  "name": "Kira Ashvane",
  "role": "protagonist",
  "voice": "Sharp, clipped sentences. Uses sarcasm as defense.",
  "motivation": "Prove she doesn't need the dragon clan's protection",
  "internal_conflict": "Craves belonging but fears vulnerability",
  "arc": "Isolation -> reluctant alliance -> trust -> sacrifice"
}

This is why dialogue doesn't all sound the same. The model has explicit voice specs per character instead of trying to infer it from nothing.

Stage 3: Chapter outlines

This turned out to be the most important stage. Each chapter gets a spec:

{
  "chapter_number": 3,
  "title": "The Binding Ceremony",
  "events": ["Kira is forced to attend the bonding ritual", "..."],
  "locations": ["Dragon temple, obsidian halls lit by bioluminescent moss"],
  "twists": ["The ritual reveals Kira has dormant dragon magic"],
  "character_interactions": [
    {
      "characters": ["Kira", "Draethor"],
      "dynamic": "hostile tension with undercurrent of curiosity"
    }
  ],
  "word_count": 2800
}

We ran an internal comparison: same book concept, same voice training, one group used the default generated outline, the other spent time customizing it.

Metric	Default outline	Customized outline
Export rate	16%	34%
Satisfaction	3.4/5	4.3/5
Regenerations/chapter	1.8	0.7
Completion rate	41%	72%

A mediocre model with a detailed outline beats a good model with a vague outline. This is the same lesson as software: garbage requirements produce garbage output regardless of how good the team is.

Stage 4: Chapter generation

The only streaming stage. The model receives book metadata, relevant characters with voice specs, this chapter's outline, previous chapter summaries for continuity, and the author's writing style samples.

Two-model strategy: Gemini Flash for all structural work (fast, cheap, good at structured output), frontier model for actual prose.

Voice training

Authors can upload 3-5 writing samples. We extract style features and use them as few-shot examples during generation.

The numbers from our data:

2.4x higher export rate with voice training
41% fewer regeneration requests
67% less manual editing

Fewer than 3 samples: marginal improvement. More than 5: diminishing returns. We were surprised how narrow the sweet spot is.

Without voice training, the output sounds like default GPT. Authors recognize it instantly and either abandon the book or spend hours rewriting. With voice training, most of the "AI slop" problem disappears. The model is capable of varied prose, it just needs examples to anchor on.

Fiction vs. nonfiction are different pipelines

Fiction uses the character graph + plot continuity pipeline above.

Nonfiction is a separate architecture. Authors upload reference materials (research papers, coaching notes, blog posts, whatever their source material is). We extract content pieces and assign relevant ones to each chapter.

Reference Files -> Content Extraction -> Book Structure Selection
                                               |
                               Chapter Outlines (with assigned references)
                                               |
                               Chapter Content (with citations)

Nonfiction with reference materials vs. without:

38% higher export rate
Satisfaction: 4.4/5 vs. 3.5/5

When the model has specific data, named studies, real quotes to ground its writing, the output gets noticeably better. Without references it falls back on training data generalizations, and readers can feel the difference.

Things we learned from 50K books

Chapter length sweet spot is 2,000-3,500 words. Below that, chapters feel underdeveloped. Above 3,500, the model starts repeating itself with different phrasing, introducing tangents, padding with unnecessary description. Above 5,000, quality drops hard. If a chapter needs to be long, splitting it works better than generating one long one.

Genre matters a lot. Romance has a 31% export rate. Literary fiction has 11%. Humor is 13%. Poetry is 9%. The pattern: AI does well with genres that have established conventions and lots of training data. It struggles with voice-dependent and creativity-dependent writing. Makes sense intuitively, but it was useful to see the numbers.

Only 23% of generated books get exported for publishing. The ones that do share traits: 3.2x more time on outline editing, voice training enabled in 74% of cases, at least one manual edit in 89% of chapters. The books that make it to publish are iterated on, not one-click generated.

Multilingual quality varies a lot. Spanish, French, German are close to English quality. Polish, Russian, Japanese, Korean are good but noticeably lower. Smaller languages are usable for drafts. This maps directly to training data volume. For authors writing in smaller languages, generating in English and translating works better than generating natively.

Stack

Frontend: Next.js, Tailwind, Supabase client
Backend: Supabase Edge Functions (Deno)
AI: Gemini Flash (structural), frontier models (prose)
30+ languages supported

Wrapping up

The main thing we took away from building this: the quality problem in AI-generated books is a specification problem, not a model problem. If you give the model a vague prompt and hit generate, you get slop. If you give it a detailed character graph, a structured outline, voice samples, and proper constraints, the output is genuinely good.

If you want to poke at it, there's a free tier that gives you a full 7-chapter book: aiwritebook.com

Happy to answer questions about the architecture, the data, or anything about AI + publishing.

Tags: #ai #writing #books #showdev #webdev #productivity

The Rational Software Engineer: a Guide to Work Time Organization

Mykyta Chernenko — Tue, 01 Jun 2021 19:52:33 +0000

Who I am and why I wrote this article

I am a software engineer who geeks on learning, using a scientific approach to solve problems, and optimizing my performance. During my work as a software engineer I often tried to understand how to optimize my productivity - I wanted to get more work done without having to do more work. And I feel like I’ve gained some insight into this topic, which may be useful for others as well. In this article, I will share my thoughts about what’s important in a good work time structure, while providing media/scientific sources and jokes whenever I can.

Why workday structure is important

There are a lot of things that contribute to how productive I am as a software engineer: how long I work, how focused I am, how often I take breaks and how I spend them - and so many more. If I structure my day correctly it can improve my productivity greatly, whereas losing control even over one aspect can lead to noticeable degradation in my productivity. So let’s figure out what a “correctly structured workday'' actually is.

Working hours

Typically, we spend 8 hours per day at work. Some of the time goes to meetings, checking emails, lunch, making coffee, and such. Writing code for 8 hours per day is not very realistic. I have seen very few individuals that manage to do it for so long while keeping productivity at a high level. Anyone who tried to code for 8 hours a day straight (especially without breaks) could tell how exhausting that was. This is the reason why there are ongoing attempts to reduce the working hours in some countries.

This leads us to a question: how much time spent on actually writing code do we expect from a software engineer? Most of my colleagues told me that, on the best days, when they are not distracted, they can write code for a maximum of 4-6 hours. Some managers (usually the inexperienced ones) could get a panic attack if you told them that their most productive developers write code for only 4 hours per day. “What the hell do they do then?!” - they might ask. Be considerate with your manager’s mental health and don’t share with them the following information: most of the people under their supervision actually do even less than that. On average, only 39% of the time at work is spent on actual work and it still doesn’t mean that a person spends this time efficiently.

Personally, I try to aim for 5 hours of focused work per day. If I have a stand-up meeting and a short lunch break at home, my working day can be as short as 5.5 hours. I feel great after such days since my output is good and I have plenty of leisure time afterwards. But remember - it only works with 5 hours of focused work. Otherwise, you can work for more than 10 hours and produce less output anyway.

However, I don’t tend to work for 5.5 hours per day as I try to be engaged with other activities besides writing code and attending the daily stand-up meeting. If I have some additional important calls, read some professional literature, participate in knowledge sharing sessions, and exercise during the lunch break my working day will typically last around 8 hours.

Focused work

By “focused work” I mean the following thing: I do the essential stuff and I work with a lot of concentration.

If we don’t have enough discipline (most of us don’t) and we have a lot of distractions (most of us do) we tend to spend time on non-essential stuff. The study suggests that checking news websites, browsing through social media, and chatting with colleagues typically consume 2 hours of an employee's working time. As well as that, 1 in 3 people say they spend 2-5 hours per day on meetings where they don’t accomplish anything. As I aim for maximum productivity, there are ways to decrease context switching with distractions, and increase focus time. I will go into detail about them in the next few paragraphs.

Skip meetings unless you are required there. As a rule of thumb: If you are not sure you need to be at the meeting - you don’t, Skip it. Yes, you will miss one semi-important once in a while but you will save dozens of hours that are much more than enough to catch up. Also, there is a good way to detect a useless meeting. If there is no agenda and you don’t understand exactly what you are going to discuss, the time is likely to be wasted. So be careful with meetings, help others understand that you value your time and that they shouldn’t invite you to meetings that are not thought through or where you are not required to be at. This rule applies to you as an organizer as well: create a meeting plan, write a good agenda, invite only necessary people, and write down a meeting summary. \ Warning - there are some meetings you don’t want to miss. E.g. if the CEO of your company wants to share something, you might consider attending - even if there is no agenda and nobody knows what’s gonna happen ( ͡° ͜ʖ ͡°)
Notifications are evil in terms of focus and productivity. Turn off your phone notifications and put your phone away to get rid of the temptation of checking it. Let’s be honest, most of the notifications you get are not important and don’t require your immediate reply. Your friends can wait for an answer whether you can join them at the bar and a new breaking news title is just another clickbait.
It’s important to create time to focus when you are not interrupted by colleagues either. A quick chat about a new version of Rust nightly and a very important question by a colleague that can be answered by googling for literally 15 seconds is not worth interruption and can wait until your break time. Book some time for your focused work in the calendar, turn on a “busy” status on Slack (or Do-not-Disturb alternative in your messenger), notify your team that you will be open for questions in an hour, or put a note on your head that you are busy. Do whatever it takes, but convey the information to others that you are not to be interrupted now. Some of the Extreme Programming proponents might disagree with this, but I believe that ad-hoc meetings or hanging on a Discord channel all day long for immediate communication are often likely to bring more harm than benefits, as they interrupt you. However, mind that if you don’t respond to people, you can block other people’s work. There are situations when a person cannot progress without your input, and it is fine if you are interrupted in such cases. Also, if your role is the lead of the team, team productivity is likely to be more important than your productivity. Being always available can be a valid option in such a case.
You are most productive when you are fresh, try to use this time for hard cognitive work. This study shows how our productivity declines with the time we work during the day. Therefore, the first working hours are likely to give the best output, use them wisely.
Prioritize ruthlessly. Set up the tasks for a day you need to do, and follow the list. It can take just a couple of minutes to make it but it helps to keep track of what you need to do and what to prioritize. If your activity right now does not contribute to the accomplishment of the daily tasks, maybe you are doing something unnecessary.
Sometimes we have a feeling that we have worked for a whole day, but when we are asked what exactly was accomplished, we don’t have a сlear answer. This can be an indicator that you were doing something non-essential - and there are opportunities to improve it. During the working day, you can write down what you were actually doing, for how long, and why you switched to the other activity. Look at the “activity” report at the end of the day. Ask yourself, whether you have been working on the stuff you should have, if there were immediate tasks, what they were and why they appeared, if you didn’t accomplish your task list, what hampered you to achieve it. You will likely find something you can eliminate to improve your productivity.
If you find it difficult to keep track of your actions, you can install a tracking system on your machine - which would take screenshots every 5/10/20 minutes, so that you’ll be able to look at the “report” after work and see your distractions.

Overtime, brrr, no thanks

Not only do we produce much less output during working overtime, but it is also connected to health risks and dissatisfaction at work, and fatigue and stress levels. As well as that, if you work for more than 55 hours per week, productivity drops so much that putting in any more hours is almost pointless according to the study from Stanford University. In other words, working more hours results in diminishing output. Personally, If I work focused for more than 6 hours a day, my mind starts to be blurry and the harder I push myself to continue working, the more demotivated I feel.

However, we all know that sometimes crunch times happen. Working longer hours to meet the release deadline, fixing a critical bug on production that affects users, having a late and urgent meeting - all of that can happen sometimes and it can be a valid reason to work longer sporadically. The most important part here is “sporadically”. If there is always a crunch before every release, most of your production releases cause bugs that you must debug late at night, and you have late meetings 3 days per week, which means that the processes suck. Work on the processes!

For example, once I was on a project where a lot of microservices were connected in a single pipeline in an “Event-Driven Architecture” manner. Once we deployed one microservice, we had to test the whole pipeline end to end as it was the only way to make sure everything works together. As a few teams worked at the same time the shifting contract between microservices was a common point of failure (this process needed improvement too, but it was a harder one to fix). If we encountered a broken pipeline after release, we would first do a revert of the last commit and deploy it once again to minimize the downtime and investigate what was wrong. Waiting for the CI/CD to finish, testing the pipeline, making another revert commit, Waiting for the CI/CD to finish, testing the pipeline again to be sure. All of that took more than an hour and would constantly make me state longer than I wanted at work. Eventually, I spent 2 days writing the first e2e test that would run before deployment, after that, I never needed to wait and check the pipeline manually after release, I knew that if there was an error, it simply would be deployed. The process was improved, the end of my workday got to be predictable again. And I’ve seen a lot of situations where overtimes could be mitigated by process improvements.

What about “work from home” and “work overtime”? It can be even harder to control that you don’t work overtime. I’ve seen plenty of developers say something on the lines of “It feels like I don’t work from home - I live at work. There is no clear separation between home and work anymore”. One good recommendation that prevents me from getting into a loop of constant overtime work is to make plans right after your working hours. For example, since I finish at 4 pm, I tend to make some plans for 5 pm: booking a gym time, getting together with a friend, or booking a table at a restaurant. That ensures that I finish on time most of the days. Obviously, if I have to work overtime to fix the production that I screwed up myself, I can cancel my arrangement, but if it’s just a “very important” meeting on whether we should introduce a new JavaScript library to handle price formatting or write the functionality ourselves at 4:30 pm, then, sorry, but I am on my way to the gym.

And there is one small but important point: If I work for 12 hours per day, I simply cannot do other enjoyable activities. And I bet you want to live life besides the job too.

Rest for your own sake

If you aim for 5 hours of focused work per day, it doesn’t mean you should do it all in one sitting. In fact, you should take breaks, and pretty often, as it helps to stay productive longer. A famous Pomodoro Technique can help you to be more productive. Cycles of Work of around 50 minutes followed by a rest for about 15 minutes is a good start. If you find it hard to concentrate for 50 consecutive minutes, you can try a free app called “Forest: stay focused” or some alternative. “Forest” turns off phone notifications and adds gamification to the process. I used it for a while and then stopped as I noticed I don’t have much problem concentrating for 30-50 minutes on my own. Also, I don’t typically track the time of 1 “cycle” of work and rest and simply take a small rest whenever I feel like it. This works for me, but maybe it will be easier for you to do it in a more controlled manner.

Try to choose a rest-activity that is different in nature from your main work. Writing code during work time and reading documentation during rest time is exhausting as they are both cognitively hard tasks. However, small exercise, meditation, a walk, some singing or playing musical instruments, and small talk generally help me get back to work with a lot of energy.

Combine different activities

It’s not always about writing code. There are a lot more activities that you can do at work and I find it more productive and entertaining to combine them. Writing code for 5 hours per day can yield good output, but if I work like that for 5 days per week, I can get a bit bored. I enjoy the days when I can write code for 3-4 hours and spend 3-4 hours on writing articles, mentoring, interviewing, education and educating, knowledge sharing, and many other activities. Being involved in different activities also promotes me to feel more satisfied with my work in general. So if you feel bored writing code, try to pick up something new, you can find it entertaining.

Education

New knowledge is important for every profession but it’s even more crucial for software engineers. Our field is constantly expanding and if you don’t want to be left on the curb, you should keep up and try to gain new knowledge whenever and wherever you can. Education is worth a dedicated article, but it’s partially connected to work time structure.

Dedicate time for education during a workweek. 3-5 hours per week should be a good start - and feel free to book this time in the calendar as you don’t want to be interrupted during the process either. If there is no common practice in the company to have dedicated time for education, try to discuss and promote this idea with your manager. It’s not as difficult as it sounds =) And If they don’t agree, maybe it’s time to dust off your CV?

Work from home

The Covid pandemic brought us a very interesting implication: a lot of people started working from home and adapting to new work routines. It was a positive change for some, others complain. There are a few useful things you should keep an eye on when you work from home.

Try to associate some space in our house with work. Dedicate a corner only for work-related activities, then it can be easier to concentrate on work there and stop working when you leave it at the end of your working schedule. If you can afford it - set a dedicated room to be “the office”.
Buy good work equipment. Make your workplace comfortable. While I don’t find it very necessary for myself, a lot of people say that a good table, chair and a couple of monitors are must-haves. Many companies have a special budget for setting up your workplace at home, so try it at least. Remember - your spine and eyes are your bread makers, just like fingers are for a pianist. Don’t go cheap on them.
Try to meet your colleagues from time to time. Working alone can be socially challenging and it’s easy to forget you’re working in a team. If it’s possible and you feel like that, try to meet your colleagues once every 2 weeks and spend some time together.

I like both the regular and home office and I would prefer to combine them. I can exercise, take shower, cook, rest and avoid distractions at home much easier. Also, I save at least an hour on commuting. On the other hand, I feel a little bit more motivated at the regular office, I enjoy talking to my team in person; and some activities like workshops, interviews, mentoring sessions, and knowledge sharing sessions are done more efficiently in real life. So try to take the best from each of the worlds if it is possible in your circumstances.

Health is crucial for productivity

Last, but not least, Health. Health is the foundation where everything starts. It’s impossible to be productive if you have a headache, right? If I don’t eat well, stop exercising for a while, have a challenging emotional situation, or have a bad sleep, my productivity plummets. To be at my peak productivity during the day, I adopted better sleep hygiene, started exercising more, lost an excessive amount of body fat, changed my diet to a much healthier one, started meditating, keeping a diary, and working at a standing desk from time to time. All of that is essential for me to feel well and be most productive.

On the other hand, a lot of developers I talk to neglect these staples of productivity and well-being. It’s not a guide about a healthy diet, but if you feel that you are slack most of the time, you want to fall asleep after 2 hours of work and you stopped seeing your knees behind your belly, it’s a good moment to get your shit together.

Exercise, keep a good diet, adopt good sleep hygiene and sign up for a visit to a physician, psychotherapist, nutritionist, and personal trainer if you need professional help or don’t know what to start with. If you lack some of the basic things, I’m sure you will see a good boost in productivity and work satisfaction once you start working harder on them.

Conclusion

There are a lot of things that play a vital role in how productive with work time structure you can be as a software engineer. I listed down most of the things I find useful for myself, but I would also like to hear what contributes to your productivity. So feel free to share in the comments or reach me in DM.

Personal Acknowledgements

Thanks to all my friends who pee-reviewed this article and especially to Maksym Bekuzarov for a thorough check and a lot of useful corrections.