Update Russian roadmap and articles

.gitignore

@@ -10,6 +10,7 @@ Gemfile.lock
 .idea/
 *.swp
 *~
+*.dtmp
 
 # OS files
 .DS_Store

.lycheeignore

@@ -16,7 +16,28 @@ https://(en|ru|zh)\.cppreference\.com/.*
 https://isocpp\.org/.*
 # Intel blocks automated clients (bots)
 https://www\.intel\.com/.*
+# cppcon.org and misra.org.uk answer 200 from browsers and residential IPs
+# (any User-Agent) but 403 to GitHub-hosted runner (datacenter) IPs — same
+# situation as cppreference/isocpp above. Surfaced once the lychee cache was
+# discarded as too old.
+https://cppcon\.org/.*
+https://misra\.org\.uk/.*
+# ko2.co.uk answers 200 from browsers and residential IPs (any headers) but
+# 415 to GitHub-hosted runner IPs — a WAF quirk on their end, same class of
+# datacenter-IP false positive as the entries above.
+https://www\.ko2\.co\.uk/.*
 # Our own /goto/ redirect pages: a PR that adds a new one always 404s until
 # it is merged and GitHub Pages redeploys, so checking them pre-merge is a
 # guaranteed false positive (chicken-and-egg).
 https://salmer\.github\.io/CppDeveloperRoadmap/goto/.*
+# sfml-dev.org is fast from normal networks (~0.1s) but repeatedly times out
+# from GitHub's datacenter runners, and lychee counts timeouts as failures.
+# Referenced from PetProjects.md in all three languages. Remove once it stops
+# flaking from CI.
+https://www\.sfml-dev\.org.*
+# autosar.org serves only the leaf certificate without the intermediate one
+# ("unable to verify the first certificate"). Browsers paper over this by
+# fetching the missing intermediate via AIA, strict TLS clients do not, so CI
+# reports an untrusted certificate. Server-side misconfiguration on their end,
+# nothing we can fix; drop this line once they fix their chain.
+https://www\.autosar\.org.*

Russian/AI.md

@@ -0,0 +1,80 @@
+# :robot: C++ разработчик и искусственный интеллект
+
+С появлением моделей, уверенно пишущих код, у многих начинающих разработчиков возник закономерный вопрос: а стоит ли вообще заходить в профессию? Вопрос честный, и отмахиваться от него «да ерунда, всё будет как раньше» неправильно. Давайте разберёмся, что происходит на самом деле.
+
+Короткий ответ: инженеры нужны, но планка сместилась. Ниже - почему.
+
+## :dna: ИИ воспроизводит то, чему его учили
+
+Модель обучена на огромном объёме уже написанного кода и по своей природе выдаёт то, что чаще всего встречалось в этих данных. Она отлично справляется с задачами, которые человечество уже решало тысячи раз: разобрать JSON, поднять HTTP-сервер, написать тесты к понятной функции.
+
+Ровно отсюда растут и её ограничения:
+
+- **Нетипичное решается плохо.** Ваша предметная область, ваши ограничения по железу, компромисс между памятью и задержкой именно в вашем случае - этого в обучающих данных не было. А инженерная работа во многом состоит из таких вот «а у нас всё не так».
+- **Перекос в сторону старого кода.** Открытого C++ кода накоплено за десятилетия, и написан он преимущественно в старом стиле. Поэтому модели охотно выдают `new`/`delete` вместо умных указателей, сырые циклы вместо алгоритмов, C-строки вместо `std::string_view`. Код будет рабочим, но не тем, который вы бы хотели видеть у себя в проекте.
+- **Уверенность не равна правоте.** Модель может сослаться на несуществующую функцию стандартной библиотеки или перепутать поведение перегрузки - и изложить это ровно тем же тоном, что и правильный ответ.
+
+## :warning: Почему в C++ цена ошибки выше
+
+В языках с управляемой памятью неверный код обычно падает громко и сразу. В C++ это не так.
+
+- **Неопределённое поведение может не проявиться на тестах.** Гонка данных, обращение к освобождённой памяти, выход за границу массива - всё это способно годами работать «нормально» на вашей машине и выстрелить у пользователя или после смены версии компилятора. Ни один тест не гарантирует, что сгенерированный код от этого свободен.
+- **Время жизни объектов - самое тонкое место.** Именно здесь модели ошибаются чаще всего: возвращают ссылку на локальный объект, захватывают переменную в лямбду по ссылке, не задумываются, кто владеет объектом.
+- **Многопоточность.** Код, выглядящий корректным, может содержать гонку, которая воспроизводится раз в неделю под нагрузкой.
+
+Вывод простой: **принимать можно только тот код, который вы способны проверить**. А чтобы проверить код на C++, нужно знать C++ не хуже, чем при написании вручную. Инструменты в помощь - санитайзеры, статические анализаторы, фаззинг - описаны в статье [Инструментарий для С++](Tooling.md).
+
+## :bulb: Узкое место разработки - не скорость набора кода
+
+Это самое важное. Работа инженера никогда не сводилась к печатанию символов. Она состоит из:
+
+- выяснения, что на самом деле нужно заказчику (обычно он и сам формулирует это не с первого раза);
+- решения, каких ошибок в системе быть **не должно**, и что делать, когда они всё-таки случатся;
+- компромиссов: скорость против читаемости, сроки против технического долга, надёжность против стоимости;
+- ответственности за результат.
+
+Ни одну из этих задач нельзя делегировать модели - не потому, что она «недостаточно умная», а потому, что это вопросы про людей, деньги и ответственность. Если приложение навредит пользователю, отвечать будет компания и конкретные инженеры, а не инструмент. В областях, где ПО сертифицируется - медицина, авионика, автомобили (см. [Стандарты и регуляторные требования](Compliance.md)) - это уже не философия, а буквальное требование: под результатом стоит подпись человека.
+
+Ещё одно наблюдение, известное задолго до нейросетей: **читать чужой код труднее, чем писать свой**. Когда кода становится больше, а пишется он быстрее, узким местом становится не написание, а понимание и ревью. Это работа для инженера, и её объём скорее растёт.
+
+## :chart_with_upwards_trend: Что действительно меняется
+
+Было бы нечестно сказать, что ничего не происходит. Происходит, и вот что видно уже сейчас:
+
+- **Рутина обесценивается.** Умение быстро написать очередной шаблонный класс само по себе больше не является преимуществом.
+- **Растёт ценность проверки и системного мышления.** Способность заметить, что предложенное решение красивое, но не выдержит нагрузки или не ляжет в существующую архитектуру, становится ключевым навыком.
+- **Планка входа поднялась.** От джуниора и раньше ждали, что он умеет писать код. Теперь всё чаще ждут, что он умеет ещё и оценивать чужой - в том числе машинный.
+
+Отсюда практический вывод: вкладываться стоит в фундамент - модель памяти, время жизни объектов, многопоточность, архитектура, отладка. Всё то, что позволяет судить о правильности решения. Это ровно то, чему посвящена [дорожная карта](README.md).
+
+## :hourglass: Ловушка для тех, кто только учится
+
+Самый серьёзный риск ИИ для начинающего разработчика - не «отнимет работу», а **помешает научиться**.
+
+Навык вырастает из борьбы с задачей: вы пробуете, ошибаетесь, разбираетесь почему, и в голове остаётся модель происходящего. Если на каждом затруднении сразу спрашивать у ассистента, задача решится, а модель в голове - нет. Через год такой практики окажется, что проверить ответ ассистента нечем.
+
+Что с этим делать:
+
+- На учебных задачах **сначала решайте сами**, а к ассистенту идите за разбором готового решения - «что здесь можно было сделать лучше и почему».
+- Просите не код, а объяснение: почему именно так, какие есть альтернативы, что сломается при изменении условий.
+- Не вставляйте код, который не можете объяснить построчно. Это правило одинаково хорошо работает и для кода со Stack Overflow, и для кода от модели.
+- Периодически пишите что-нибудь вообще без ассистента - чтобы честно видеть свой реальный уровень.
+
+## :handshake: Как пользоваться с пользой
+
+- **Как ускоритель рутины:** шаблонный код, заготовки тестов, разбор незнакомого API, черновики документации.
+- **Как объясняющий собеседник:** «почему компилятор ругается вот так?» - ошибки в шаблонах C++ модели расшифровывают заметно понятнее, чем компилятор.
+- **Как навигатор по чужой кодовой базе:** быстро понять, где что лежит и как связано.
+- **Как рецензент:** попросить найти проблемы в вашем коде. Не как истина в последней инстанции, а как ещё одна пара глаз.
+
+И три правила, о которых лучше помнить всегда: проверяйте сгенерированное, соблюдайте политику компании по передаче кода во внешние сервисы, помните про лицензионные риски. Подробнее - в разделе про [AI-инструменты](Tooling.md).
+
+## :telescope: Чего никто не знает
+
+Честно: как будет выглядеть профессия через десять лет, не знает никто - ни авторы этой карты, ни авторы самих моделей. Любой, кто уверенно предсказывает и «всех заменят», и «ничего не изменится», выдаёт желаемое за факт.
+
+Что можно сказать с уверенностью: спрос на людей, которые понимают, как работают системы, и способны отвечать за результат, пока никуда не делся. Инструменты в разработке менялись всегда - ассемблер, компиляторы, IDE, автодополнение, поиск в интернете. Каждый раз звучало «теперь программировать сможет кто угодно», и каждый раз работы становилось больше, а не меньше, потому что дешевеющая разработка открывала новые задачи. Нынешний виток может оказаться и другим - но ставить на то, что глубокие знания вдруг обесценятся, пока оснований нет.
+
+---
+
+[**На главную страницу**](README.md)

Russian/Books/Middle.md

@@ -12,6 +12,10 @@
 
     Книга Мейерса останавливается на C++14, а эти два тома продолжают с того места, где она заканчивается. Каждый из них системно разбирает всё, что добавил соответствующий стандарт — как возможности языка, так и библиотеки — с практическими примерами и советами, когда стоит (и когда не стоит) применять новые инструменты.
 
+- [Николай Джосаттис - C++ Move Semantics: The Complete Guide (ENG)](https://leanpub.com/cppmove)
+
+    Move-семантика — одна из тех тем, которые «вроде понятны», пока не начнёшь разбираться в деталях: когда компилятор сам применяет перемещение, чем `std::move` отличается от `std::forward`, почему перемещение иногда молча превращается в копирование и как правило пяти связано с `noexcept`. Книга разбирает это последовательно и с примерами. Одна из самых частых тем на собеседованиях уровня Middle.
+
 - [Клаус Иглбергер - C++ Software Design: Design Principles and Patterns for High-Quality Software (ENG)](https://www.amazon.com/Software-Design-Principles-Patterns-High-Quality/dp/1098113160)
 
     Современный взгляд на паттерны проектирования, написанный специально для C++. Книга показывает, как классические паттерны выглядят на базе современных идиом — семантика значений, type erasure, `std::variant` — вместо глубоких иерархий наследования. Отличный мост между знанием языка и умением проектировать на нём.