В инженерной практике мониторинг — это не «дополнительный сервис», а такой же элемент инфраструктуры, как сеть, диски и резервное копирование. Пока он работает, его не замечают. Но стоит ему исчезнуть — и даже формально живые системы начинают ломаться тихо и незаметно.
На работе почти одновременно вылезли две разные проблемы — и обе в итоге привели меня к системе мониторинга Zabbix.

1. Как «умер» сервер бэкапов и почему мониторинг умер вместе с ним

Сначала «умер» сервер резервного копирования АТС Asterisk. Причём умер хитро: пинг есть, а всё остальное — нет. Попытки реанимации ни к чему не привели, поэтому принял волевое решение — переустановить систему с нуля.
Резервное копирование телефонии у нас устроено не самым тривиальным образом: бэкапы делаются через ZFS‑снапшоты файловой системы. Из снапшота можно восстановиться обратно — не быстро и не просто, но можно.
Есть нюанс: чтобы получить ZFS‑снапшоты на клиенте, ZFS должен быть и там. Раньше ZFS был корнем системы, теперь — просто отдельный пул. Нашёл рабочую инструкцию по установке ZFS на Debian 12 — «Install ZFS On Debian 12» https://blog.programster.org/install-zfs-on-debian-12, установил ZFS, настроил Zrepl — утилиту, которая вытягивает снапшоты с сервера. В итоге получил снапшоты за последний месяц.
И тут всплыла проблема мониторинга. Как узнать о недоступности сервера как можно раньше?
Раньше скрипт мониторинга создания снапшотов жил… на самом сервере бэкапов. Сервер умер — мониторинг умер вместе с ним. Классика.
Решение напрашивалось само собой: выносить мониторинг в Zabbix. Архитектура у него простая — центральный сервер и агенты на хостах, которые собирают метрики (CPU, память, сеть и т.д.). Обычно этого хватает, чтобы понять, что серверу плохо.
Но метрика «есть ли свежий ZFS‑снапшот» из коробки не поставляется. Пришлось добавить свою.
В Zabbix есть механизм пользовательских параметров (https://www.zabbix.com/documentation/2.0/ru/manual/config/items/userparameters) — можно самому описать метрику и определить скрипт, который возвращает её значение. В моём случае это проверка наличия свежего снапшота. На сервере Zabbix я повесил триггер: если снапшота нет или данных нет вообще (читай — сервер умер), значит пора бить во все колокола.
Посмотрим, как это покажет себя в бою.

2. Ночные обзвоны инженеров и иллюзия надёжности

Вторая проблема — сервис ночного обзвона дежурных. АТС звонит инженеру, зачитывает заявку и фиксирует его ответ. При этом сервисная система наивно уверена, что звонок всегда будет совершен.
А реальность, как обычно, сложнее: АТС может не дозвониться по тысяче причин.
Здесь я тоже решил «обмазаться» мониторингом через Zabbix, но уже другим способом. Не Zabbix собирает метрики, а скрипт сам отправляет их в Zabbix через zabbix_sender.
Например, если ночной звонок инженеру успешно отправлен:

zabbix_sender -z 192.168.0.1 -s "asterisk" -k call.ok -o 1

В чём разница с первым кейсом: там проверка идёт регулярно, а здесь звонки могут быть, а могут и не быть — и это нормально.
Но копнув глубже, выяснилось неприятное: АТС не возвращает в скрипт ошибку, если звонок реально не состоялся. Чтобы отследить факт реального звонка, нужно использовать AGI (Asterisk Gateway Interface), а это уже серьёзная переработка кода сервисной системы.
Мои метрики по факту мониторят результат работы скрипта, а не саму АТС. Не идеально, но всё же лучше, чем ничего.

3. Про обучение, ожидания и реальность

Прошёл тренажёр по SQL на sql-academy.org. Думал, сейчас ещё и сертификат дадут — но сертификаты только за деньги. Бизнес, ничего личного.
В итоге прошёл курс без сертификата. И, честно говоря, это вообще не проблема. Главное — знания. SQL я заметно подтянул: даты, аналитические функции, группировки, подзапросы — со всем этим теперь чувствую себя гораздо увереннее. Пробелы ещё есть, значит есть куда расти.
С курсом «Добрый, добрый C/C++ с Сергеем Балакиревым» вышло разочарование. Курс хороший, но он для новичков. Менять местами два числа и подробно разбирать if и while — занятно, но этот уровень я уже давно прошёл.
Поэтому переключился на «C++ базовый курс» на YouTube — https://www.youtube.com/playlist?list=PL3BR09unfgciJ1_K_E914nohpiOiHnpsK. Он как раз для тех, у кого C++ не первый язык. Курс хвалят, посмотрим.
Заодно глянул видео Антона Полухина «Незаменимый C++» — https://www.youtube.com/watch?v=LZflL44SVVY. Автор жжёт и пепелит: показывает, где C++ используется (спойлер — почти везде), и почему он выигрывает по производительности. Но честно говорит и о проблемах: высокий порог входа и вопросы безопасности. Отдельно хорошо объясняет, почему компилятору Rust до компилятора C++ ещё далеко — C++ компиляторы 30 лет пишут всем миром и оптимизируют огромное количество очень специфических кейсов.

P.S.
Во вторник у меня был день рождения — исполнилось 47 лет. Время летит всё быстрее, но с годами приходит спокойствие и понимание: многие ситуации уже видел, через многое прошёл и примерно знаешь, куда смотреть, когда что-то снова начинает ломаться.

Чем дальше работаешь инженером, тем чаще ловишь себя на простой мысли: поверхностных знаний уже недостаточно. Хочется понимать, как всё устроено внутри — от памяти и указателей до архитектуры приложений. Этот текст — заметки из очередной попытки копнуть чуть глубже.
Продолжил изучение низкоуровневого программирования.
Начал смотреть курс по C++:
https://www.youtube.com/playlist?list=PL3BR09unfgciJ1_K_E914nohpiOiHnpsK
Курс хороший, но объективно сложный. Он рассчитан на студентов МФТИ — победителей олимпиад, с сильной базой по C и математике. Уже первая домашка — вычислительная геометрия и пересечение трёхмерных треугольников. Вычислительная геометрия — точно не мой конёк.
При этом курс мне понравился. Преподаватель умеет объяснять сложные вещи просто и интересно — редкое качество. Поэтому сейчас смотрю его в «радио‑режиме»: для понимания общей теоретической базы, без попыток всё сразу воспроизвести на практике.
Отдельно зашла лекция про указатели. Особенно цитата:
«C++ может убить вашего котёнка, даже если у вас нет этого котёнка».
Очень наглядно про работу с памятью: можно освободить больше, чем у тебя вообще было.
Низкоуровневое программирование я бросать не собираюсь, но буду искать курс более адекватный моему уровню. Задача простая: понять базовые концепции и написать небольшой проект. Упарываться в хардкор на годы вперёд цели нет. Это обучение — для расширения инженерного кругозора.
Инженер, который ничего не изучает и ни в чём не разбирается, — мёртвый инженер.
Поэтому решил реализовать мечту детства — написать компьютерную игру. Остановился на классической игре «Память». Есть поле с карточками: можно открыть только две, если они совпали — пара исчезает. Игра простая, мегапроект не нужен.
В качестве движка выбрал Phaser:
https://phaser.io/
Пока изучаю плейлист «Phaser 3 Game Tutorial – Solitaire»:
https://www.youtube.com/playlist?list=PLmcXe0-sfoSh1o3fm-_2JOod-wRUxnqb_
И вот тут началось самое интересное. Игра простая, а вопросов сразу вагон:
как организовать конечный автомат состояний? какая будет система событий или команд? где проходит граница между логикой и рендерингом?
Решил, что игру буду делать под Telegram. И тут всплыли вопросы деплоя: как поднять сервер с игрой на Angie со SSL, как правильно подключить её к Telegram, как всё это обслуживать.
Заодно захотелось попробовать Claude. А как его настроить? А как встроить в процесс разработки?
В итоге парадоксальная ситуация: игра примитивная, а чтобы получить законченное решение, нужно приложить неожиданно много усилий. И, пожалуй, в этом и есть главный урок.
В итоге я в очередной раз убедился: такие эксперименты ценны не столько результатом, сколько тем, что они вскрывают по ходу дела. Даже простой проект довольно быстро показывает, где знаний не хватает, где инструменты упираются, а где архитектура начинает давать сбои. Поэтому я и продолжаю этим заниматься — спокойно, без спешки и иллюзий, воспринимая такие задачи как нормальную часть инженерного роста.

От дебага звонка до собственной игры в Telegram. Иногда кажется, что рабочий день - это просто череда мелких задач. А
потом внезапно понимаешь: ты уже три часа дебажишь звонок, который «не
идёт».

Asterisk и звонок напрямую
На работе столкнулся с занятной историей. Не мог позвонить на сотовый
номер по определённому транку. Перебрал параметры, покрутил настройки
- тишина.

В какой-то момент нашёл простое, но неожиданное решение для
тестирования: звонить прямо из командной строки.

 bash
asterisk -rx "channel originate SIP/89876543210@beeline application Playback demo-congrats"

Команда инициирует вызов и проигрывает файл. Никакой магии - просто
прямой вызов в Asterisk.

В итоге всё-таки дозвонился. Иногда лучший способ понять, что происходит
внутри, --- убрать всё лишнее и пойти напрямую.

Бэкап виртуальной машины в Proxmox
Ещё одна хитрая задача --- виртуальная машина в Proxmox с двумя дисками:
системный (Debian) и большой диск под бэкапы (scsi1). Нужно было сделать
резервную копию только системного диска.

Решение оказалось элегантным: остановить ВМ, временно удалить второй
диск из конфигурации, выполнить обычный бэкап через vzdump, а затем
вернуть диск обратно.

 bash
qm stop 100
qm set 100 --delete scsi1
vzdump 100 --mode stop --storage local --compress zstd
qm set 100 --scsi1 san01_lun1:0.0.1.scsi-3600000000000000000e0000000040001
qm start 100

В архив попадёт только первый диск. Минимум шаманства - максимум
контроля.

Memento mori - игра для Telegram
Параллельно начал делать свою HTML5‑игру для Telegram. Назвал её
«Memento mori».
Это небольшая казуальная игра на тренировку памяти: открываешь пары
карточек и стараешься уложиться в минимальное число ходов. Решил сделать
её в готической эстетике --- вампиры, скелеты, мрачная палитра. Почему
бы и нет.
Когда декомпозировал задачу, понял масштаб.

Что нужно собрать
- Telegram‑бот для запуска Mini App.
- Backend с авторизацией через Telegram и хранением пользователей и
результатов.
- Frontend с двумя сценами и игровым полем на Phaser.
- Лендинг для тех, кто зайдёт не из Telegram.
- CI/CD через GitLab, Docker Compose и SSL.
- Claude AI для помощи в разработке.
По отдельности всё выглядит просто. Вместе - уже задача со звёздочкой.

И самое забавное: взаимодействие с игровым движком - процентов десять
от общего объёма работ. Основное время уходит на инфраструктуру,
авторизацию, деплой и окружение.
Фронтенд и бэкенд решил писать на Next.js - один репозиторий, проще
отлаживать и поддерживать.

С Phaser поразбирался отдельно. Для React он ощущается как чёрный ящик.
Всё рисуется на Canvas. А Canvas - это просто растровое полотно:
браузер не знает ни про кнопки, ни про спрайты. Есть только картинка.
Нужно изменить сцену - перерисовываешь всё целиком.

Если нужно из React «достучаться» до игры - используешь ref.
Если из Phaser передать что-то наружу - EventEmitter.
Очень напоминает работу с фреймами в старые добрые времена.

Пока показать из кода особо нечего - только репозиторий:
https://gitlab.com/orion55/memento
Но картинки для двух уровней уже сгенерировал с помощью ChatGPT.

Чем дальше вникаю, тем яснее вижу: игра - это не про спрайты. Это про
архитектуру, окружение и десятки маленьких решений, которые должны
сойтись в одну систему. Дорогу осилит идущий.

Продолжаю делать компьютерную HTML5-игру для Telegram «Memento mori» https://gitlab.com/orion55/memento

Небольшая казуальная штука на память: открываешь карточки, ищешь пары и стараешься уложиться в минимальное количество ходов.

Решил писать её вместе с AI Claude. И вот тут началось интересное. Я попросил реализовать авторизацию через Telegram и сохранение пользователей в базу --- фича сложная, многоступенчатая. Claude справился. Не с первого раза, но в целом достойно.

А потом я попросил написать API для таблицы лидеров - и начался цирк. Сначала мне предложили двухуровневый кэш: промежуточную таблицу в PostgreSQL плюс Redis. При том, что это пет-проект и трафика там кот наплакал. Попросил упростить - без Redis и без лишних сущностей. Тогда появилось материализованное представление. Объяснить, что мне нужен обычный SQL-запрос с нормальными индексами, удалось далеко не сразу.

В какой-то момент стало ясно: дело не в модели, а в ТЗ. Без нормальной постановки задачи результат получается соответствующий. Старая истина подтвердилась --- без ТЗ результат ХЗ. В итоге почти всю неделю писал документацию к проекту: формализовал входы, выходы, граничные случаи. Почувствовал себя бизнес-аналитиком.

Потом решил пойти дальше --- создал саб-агента в Claude, который делает код-ревью. И внезапно выяснилось, что только что написанный код таблицы лидеров содержит уязвимости. Отдельный квест - актуальность знаний. Последнюю версию NextJS Claude знает не лучшим образом, поэтому подключил Model Context Protocol (MCP)-сервер Context7 https://github.com/upstash/context7 Он подтягивает свежую документацию и сильно помогает.

В итоге, чтобы получить от Claude Code «просто нормальный код среднего уровня», приходится строить мини-фабрику: MCP-серверы, субагенты, маршрутизацию контекста, правила. Ты вроде просил фичу, а в итоге проектируешь среду, в которой она вообще может быть сгенерирована. И быстро понимаешь: всё упирается не в хитрые промпты, а в качественный бизнес-анализ и документацию. Пока не описаны процессы, границы, исключения и критерии «готово», агент будет уверенно ехать в разные стороны.

По ощущениям это уже чистое метапрограммирование. Ты не пишешь код --- ты строишь систему, которая пишет код. И это неожиданно похоже на generic'и: не «сделай Х», а «сделай механизм, который стабильно делает Х при разных входах». Самой сложной частью оказывается не генерация, а проектирование условий, в которых она становится предсказуемой.

Продолжаю делать компьютерную HTML5‑игру для Telegram «Memento mori». Неделя прошла не в геймдеве, а в тихой и упрямой войне под названием DevOps. Проект мало написать — его нужно доставить на удалённый сервер, который живёт 24/7 и не интересуется твоим вдохновением.

В качестве CI/CD я использую GitLab. Он получает код, по кнопке собирает Docker‑образы, складывает их в свой registry и запускает команды на удалённом сервере, чтобы вытянуть свежие образы и перезапустить контейнеры. Схема известная и рабочая. Но дьявол, как обычно, в нюансах: права, зависимости, мелкие несостыковки, которые съедают часы и нервы.

В 2026 году использовать Nginx как реверс‑прокси уже выглядит странно. OpenSource‑версия фактически умерла, активное развитие уехало в коммерческую сторону. Русская команда сделала форк и назвала его Angie https://angie.software/ — по сути, тот же Nginx, но с новыми модулями: Brotli, защита от DDoS, поддержка HTTP/3 и главное — модуль ACME.

Раньше всё было просто и муторно одновременно. Нужен SSL — ставишь certbot, получаешь бесплатный сертификат от Let’s Encrypt, через 90 дней обновляешь. Certbot в cron, то работает, то нет. И в какой‑то момент сайт внезапно с просроченным сертификатом. Мелочь, а геморроя вагон. В Angie модуль ACME берёт это на себя — сам получает и продлевает сертификаты, нужно только один раз грамотно настроить. Вот хороший видеоурок «Автоматические TLS‑сертификаты: модуль ACME» https://www.youtube.com/watch?v=ywJQ25tDwaY

И тут я решил усложнить себе жизнь — купить VPS в Латвии. Поднял сервер на 80‑м порту, подключил домен, всё заработало с первого раза. Почувствовал себя победителем. Но как только получил сертификат и включил 443 порт — сайт умер. Я перелопатил конфиги Angie, сетевые настройки, проверил TLS руками через openssl, убил кучу времени. А потом выяснилось, что Роскомнадзор активно режет зарубежные хостинги по 443 порту — в поисках сервисов из трёх букв, которые нельзя называть. Перенёс проект на хостинг в Санкт‑Петербург — и всё заработало мгновенно. Борьба идёт, но явно не с теми.

Вот сайт проекта https://mementus.ru/, а вот бот https://t.me/memento_mori_game_bot. Пока это даже не бета, а скорее заглушка, но фундамент уже стоит.

Смысл этой игры — не деньги, а прокачка навыков программиста и DevOps. Есть золотое правило: внедрять за раз одну новую технологию, а остальное держать старым и проверенным. Я же умудрился параллельно учить NextJS, Phaser, Angie и Claude AI. Вероятность не довести проект до конца при таком наборе растёт не линейно, а умножается. Технологии могут быть модными, но проблемы никуда не исчезают — их просто красиво асфальтируют маркетингом.

На работе, как только я рассказал про игру, посыпались вопросы. «А что будет, когда Telegram отключат?» — пока его собираются не отключать, а замедлять и отпиливать функции. Даже если полностью прикроют, технически переехать в VK или куда‑то ещё не проблема. Технической разницы почти нет.

«Сколько заработаешь?» — нисколько. Это pet‑проект. Чтобы зарабатывать, надо сначала понимать, кому ты продаёшь, какие у людей боли и за что они готовы платить. Игры для детей, подростков и взрослых — это три разных мира. А в простых головоломках уровня “три в ряд” конкуренция такая, что без продуманной стратегии туда лучше не лезть.

«Когда выйдет в Steam?» — никогда. Там и без меня 80% проектов очень странного качества. Пополнять этот список желания нет.

Самое забавное — я думал, что основная работа будет в игровом движке. По факту backend, frontend и DevOps съедают процентов 95 времени. До самого геймплея добираюсь урывками. И это я ещё не трогал полноценный мультиплеер с сетевым взаимодействием и многопоточную обработку данных.

Смысл всего этого один — довести проект до конца, несмотря на инфраструктурные грабли, блокировки, несовпадение ожиданий и реальности. Потому что прохождение курсов — это иллюзия прогресса. А реальный проект быстро показывает, чего ты на самом деле стоишь.

Пока делаешь пет‑проект, постоянно натыкаешься на вещи, о которых обычно не думаешь. На этой неделе я воевал не с кодом, а с дизайном.

Продолжаю делать компьютерную HTML5-игру для Telegram «Memento mori». Вот сайт проекта https://mementus.ru/, а вот бот https://t.me/memento_mori_game_bot. Следующий этап этой невидимой войны — дизайн. И вот тут быстро выяснилось, что красивые ИИ-эскизы и реальная вёрстка — это две большие разницы. Картинка на одном телефоне сидит нормально, на другом уже уехала, а там, где нужны точно поставленные интерактивные элементы, всё начинает разваливаться при первом же масштабировании.

Я вспомнил одну из прошлых работ. У нас был дизайнер, который рисовал великолепные макеты, но верстать их было сущим наказанием. То плавные линии. В природе ведь нет прямых линий, а вот вёрстка живёт исключительно прямоугольными блоками, то многоцветные градиентные тени — нет таких теней в CSS, то бесконечные оттенки чёрного, которые вроде бы разные, но попробуй потом всё это аккуратно собрать в интерфейс. Теперь в этой роли оказался уже я сам, только вместо живого дизайнера — ИИ. И, как выяснилось, ИИ тоже умеет рисовать красиво, но совершенно не думает о том, как это потом собирать руками.

В итоге пришлось расчехлять Photoshop и доводить всё напильником. Чтобы был понятен масштаб бедствия: я попросил ИИ нарисовать обычный крестик для закрытия окна в готическом стиле. Он нарисовал не кнопку закрытия, а какой-то мрачный крест с черепом, словно это артефакт из тёмного фэнтези. Я попросил сделать проще — получил тот же крест с черепом, только уже без фона. Убрал слово «готический» — и меня мгновенно унесло в киберпанк. В какой-то момент я плюнул и просто сам вырезал фон в Photoshop, чтобы получить нормальный объёмный металлический крестик, а не очередной полёт чужой фантазии.

Потом я решил доверить ИИ ещё и вёрстку страниц. И вот здесь стало совсем весело. Фронтенд у него получается откровенно плохо: то лишние обёртки лепит, то, наоборот, не хватает служебных блоков, без которых ничего нормально не тянется и не центрируется. На одном разрешении всё ещё как-то держится, а стоит только изменить размер области — и весь интерфейс ломается на глазах. При этом с бэкендом у ИИ ситуация заметно лучше. Если чётко расписать алгоритм, входные данные, выходные данные и граничные случаи, то код на серверной части он выдаёт вполне вменяемый.

На работе в это же время всплыла другая история. Корпоративная система неверно ищет телефонные звонки в базе данных АТС. Я написал подробное техзадание: что есть, в чём проблема, как её исправить, какие есть нефункциональные требования. Специально расписал всё очень подробно, почти как для джунов: с примерами кода, подсказками и пояснениями по ходу. Просто я не знаю реальный уровень наших программистов, а потому решил, что лучше переобъяснить, чем потом разгребать недопонимание и костыли.

Я даже отдельно спросил у начальника программистов, нормальна ли такая степень детализации и справятся ли они с задачей. На что он мне ответил фразой, которая, кажется, идеально описывает весь отечественный энтерпрайз: «Наши программисты закостылят что угодно». И вот в этот момент я почему-то испытал не ужас, а даже какую-то гордость за наш отдел. Потому что, как ни крути, в этой фразе было не только про костыли, но и про удивительную инженерную гибкость.

В итоге я поймал себя на простой мысли. ИИ хорошо помогает там, где всё можно строго формализовать: алгоритмы, данные, граничные случаи. Но как только начинается дизайн, интерфейсы и реальная вёрстка под десятки экранов — приходится возвращаться к старому инженерному инструменту: голове и напильнику. Пет‑проекты хороши тем, что очень быстро ставят всё на свои места.

Иногда обычная рабочая неделя неожиданно превращается в сборник технических историй: немного администрирования, немного борьбы с кривыми конфигами, немного экспериментов с AI и параллельно разработка собственной игры. Каждая такая задача сначала выглядит мелкой и рутинной, но стоит копнуть глубже — и она внезапно превращается в маленькую археологическую экспедицию по старому коду, странным решениям и забытым настройкам.
На работе возникла задача синхронизировать фамилии из телефонного справочника с названиями телефонов. Ситуация типичная: условно телефон закреплён за Ивановым, Иванов уволился, вместо него пришёл Петров — а телефон продолжает показывать, что это Иванов. Просто потому, что никто не поменял CallerID.
Проблем оказалось две. Первая — в конфигурации АТС числилась куча телефонов, которые физически зарегистрированы и при этом отсутствуют в справочнике. Лишний мусор. Пришлось написать скрипт, который прошёлся по конфигу и вычистил всё, что не используется.
Вторая проблема оказалась веселее: конфигурационный файл с телефонами оказался «битый». У Asterisk есть забавная привычка — при одной ошибке он может орать, что всё пропало, но при этом спокойно игнорировать опечатки в ключах. Например: pickguproup вместо pickupgroup или usename вместо username. Плюс у части телефонов вообще пустые значения в callerid.
Руками такое не исправишь: телефонов больше трёхсот. Поэтому я написал несколько скриптов, которые прошлись по конфигу, поправили ключи, проверили callerid и привели всё в порядок. В итоге удалось восстановить 29 «сбойных» телефонов — и заодно отсортировать результаты по алфавиту.

Параллельно продолжаю делать HTML5‑игру для Telegram «Memento mori». Вот сайт проекта [https://mementus.ru/](https://mementus.ru/) , а вот бот [https://t.me/memento_mori_game_bot](https://t.me/memento_mori_game_bot) .

Читая документацию по Claude, я долго удивлялся: зачем там столько сущностей — субагенты, скилы, оркестрация. На практике быстро выяснилось, что у AI память очень короткая. После длинного диалога он начинает забывать критические детали.
Отсюда и появляется архитектура из маленьких агентов. Универсальный «многорукий» помощник, который делает всё сразу, работает плохо. А вот отдельный агент с чёткой задачей — например проанализировать код или подготовить текст — справляется заметно лучше.
Хорошо об этом написано в статье «Контекст‑инжиниринг для coding‑агентов: почему агент тупит не из‑за модели» [https://habr.com/ru/companies/cloud_ru/articles/1008522/](https://habr.com/ru/companies/cloud_ru/articles/1008522/)
На практике диалог с coding‑агентом быстро превращается в стабильный шаблон:
Сначала: «прочитай эти файлы и объясни, как устроен модуль и где могут быть баги».
Потом: «предложи план изменений по шагам, код пока не трогай».
И только после этого: «вноси изменения строго по плану; если от него отходишь — объясни почему».
По сути, текстовые файлы и куски контекста просто путешествуют между разными агентами. Когда задача чёткая и ограниченная — например «внести правку в код» или «проанализировать текст» — всё работает отлично. Когда задача становится слишком общей, агент начинает быстро забывать детали.

Был и забавный эпизод. Перестало собираться приложение. Я был уверен, что AI исправит это за пару минут. В итоге он два часа создавал и удалял строки, переписал половину проекта и почти всё вернул обратно. Ошибка же решилась заменой одной строки. Единственное полезное открытие из этой истории — ключ claude --dangerously-skip-permissions, который отключает бесконечные запросы подтверждения.

Но случилось маленькое эпохальное событие: вчера я наконец добрался до работы с игровым движком Phaser. Прошёл ровно месяц с начала проекта.
За это время удалось:
- создать мини-лендинг для [https://mementus.ru/](https://mementus.ru/)
- реализовать backend: авторизацию через Telegram, таблицу лидеров и игровые сессии
- настроить интеграцию с Telegram
- собрать CI/CD и перенести проект на VPS
- подготовить дизайн экранов
- реализовать три интерфейса: начало игры, таблицу лидеров и настройки

Я наивно думал, что такой объём работы уложится в одну‑две недели. Но без всей этой «невидимой» подготовки сам игровой процесс просто не запустить.
Плюс параллельно пришлось осваивать кучу новых инструментов. И главный вопрос всё время был не «что делать», а «как именно это сделать».
Но проект движется. А значит всё идёт правильно.

И чем дальше, тем яснее простая мысль: большие проекты собираются из десятков мелких задач, которые по отдельности выглядят совершенно безобидно. Сегодня ты просто «чуть‑чуть поправил конфиг», завтра «немного поговорил с AI», а через месяц внезапно понимаешь, что у тебя уже работает половина игры — хотя вроде бы всё это время занимался какой‑то ерундой.