From Book Notes to Agentic Development: a Subscriber AMA

The morning starts around seven: Alexander takes Lyusya, an Australian shepherd, to one of the two parks by the house — Berezovaya Roshcha or Khodynka, opposite the CSKA stadium. The walk runs about half an hour, so the conference talk is picked to fit that slot: forty-minute videos he finds too long and dull, twenty-minute ones ideal. Back home: breakfast, work loaded onto the agents, a look at what they did overnight, and a chat with a model about the talk that ends in a draft. By ten he would usually reach the office by Belorusskaya, grabbing coffee on the way. The day was then booked solid with meetings: one-on-ones, syncs on large projects, all-hands of the technical leaders, reliability meetings, interviews with technical directors, promotion cases to assess. At some point, he admits, you start resembling a router forwarding information along its routes — so agents that take a piece of research or code in a gap between meetings were a relief.

The evening means a taxi at half past six, the last meeting sometimes held from the back seat, a second walk with the dog, bedtime stories for the children (the youngest, though, has switched to a voice assistant) and a little more work after lights out. The deal with his youngest son to do chess puzzles in Duolingo before bed works both ways: the boy tires and sleeps sooner. There is no magic time-turner, Alexander stresses, and he thanks his wife Nastya, who takes on more at weekends. He keeps several books going in parallel and picks by mood; less than half of his library, he corrects himself, is in English, a translation reads faster but yields less: slow reading leaves room to ask how the new knowledge differs from his picture of the world. He rarely abandons a book: Ilyahov's manual on concise writing sat a third read for almost a year until its imperative style became bearable; he stopped reading Nassim Taleb once The Black Swan's substance fitted, for him, on one sheet of A4.

Alexander describes his publishing process as six steps, all starting with a D. First, discovery: Telegram channels, Google and YouTube recommendations, subscriptions to industry podcasts, mail from digital libraries. Then daily reading of articles and chapters and watching video — an hour on the elliptical fits two or three twenty-minute talks. The third step is discussing the material with a model, because few people around him read as many white papers; it helps to ask it to challenge the argument rather than nod along. The fourth is a draft built from that discussion, with context about the author and conference and links to earlier material. Then editing with fact-checking: verify the references and make sure your own thoughts from the discussion survived — if not, there is nothing worth publishing. The last step is timing: a talk by a former VP of architecture and platform engineering at eBay, who three years on told the London sequel to his delivery-pipeline story, waits for its slot. His own reviews, Alexander says, work as external memory.

He does have a separate knowledge base — an experimental project with ingestion, hybrid search, a vector database and graph links — but at his scale a repository wins: exports migrated out of Telegram and Medium, Markdown files and skills for different kinds of material. Asked in the chat about prompts modelled on courtroom interrogation, he answers that a skill is baked-in prompts, tools and an algorithm; the models of late summer 2026 follow instructions well enough, but it is worth checking whether the skill genuinely beats working without it. System Design Space grew out of unfinished business: a book demanded years of life for tens of thousands of roubles, so an interactive site appeared instead. Calm linear reading will come with a book from the Piter publishing house, whose contract still waits to be signed; a long-lived branch meanwhile holds a 2.0 version with exercises, hints, playgrounds and quizzes. The bottleneck is his own review speed — a textbook example, he says, of how not to assemble an increment.

Writing good code is no longer enough: an engineer is expected to understand the domain, do system design and check automatically that everything works. Juniors, Alexander argues, need a T-shape rather than a dive into one domain, because nobody can guess what will pay off. To school leavers he wishes something other than becoming a priest of the machine god: if the learning cycle has not changed, a student will do everything through an agent and, without one, cannot work out what went wrong. With his eldest son Pasha, a third-year game design student, he has proposed building a game together, possibly about system design: mechanics from his son, engineering from him. Growing beyond team lead is the right place, the right time and readiness; the right place he unpacks through Westrum's culture types, where Boeing with its detaching doors lands in the bureaucratic one that kept the problem inside a unit. A simple test is a diary of good and bad days. His own last day after ten years at the company is 31 August; he plans to be in London around November.

Alexander recommends side projects as a way to hold an opinion of your own — unlike top managers who spend three years talking about AI and then look up statistical models on Wikipedia. In your own project you are the CEO, the product manager and the CTO at once: no handovers between stages, but every blunder is yours too. Hence his architectural demands: test hypotheses fast, run cheap, heal itself, and never need agents told how to build a feature — what to build he is happy to explain. His site has grown a folder of deterministic checks: terminology, content, dependencies, diagrams, internationalisation, budgets for static assets and JS. A MacBook Air overheats on a full rebuild; frequent scenarios like adding content or posts moved to incremental checks, for local build speed and CI minutes. An incident-analysis agent will work where practices, documentation and runbooks already exist; in large companies implicit knowledge gets in the way — an un-onboarded senior would fix an incident worse than an agent. The closing question from Igor about AGI and ASI he answers by pointing at Eliezer Yudkowsky's book, whose title is a warning: if someone builds it, we all die.