Codex вместо документации: как я собрал лабораторию по Node.js, пока учил Event Loop

Когда фронтендер переходит на бэкенд, первая ловушка — не синтаксис, а ощущение, что ты уже пишешь работающий код, но не понимаешь, что происходит под капотом. Разработчик Nneon столкнулся с этим на своём проекте и решил не читать теорию по кускам, а попросить Codex собрать интерактивный стенд, где можно запускать эксперименты и видеть реальный порядок событий. Получился Runtime Lab — open-source-проект на 24 главы, доступный как сайт и как репозиторий на GitHub.

Почему писать код стало легко, а понимать его — нет

Работая над Nneon — платформой для публикации связанных языковых версий одной записи — автор впервые плотно распробовал Codex. Агент собирал CRUD, тянул API, писал миграции и чинил типовые ошибки в рамках одной задачи. Производство синтаксиса перестало быть узким местом: человек без серьёзного опыта разработки, но с прямыми руками, уже способен закрыть заметную часть потребностей малого бизнеса.

Проблемы начинаются дальше. Где провести границы сервисов. Как не потерять данные при повторной доставке сообщения. Почему растёт память. Где прячется N+1-запрос. Как не заблокировать Event Loop тяжёлым вычислением. Работа разработчика не исчезла — она сместилась от «как написать этот цикл» к «что здесь должно происходить и как понять, что оно развалилось».

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

Roadmap с YouTube и Event Loop, который не укладывался в голове

Автор нашёл на YouTube roadmap перехода из frontend в backend на Node.js — он почти точно совпадал с личной ситуацией: NestJS уже использовался в проде, фронтенд не вызывал трудностей, а знания о runtime, базах данных и инфраструктуре были собраны кусками.

Первым серьёзным препятствием стал сам runtime: Event Loop, очереди задач, демультиплексор событий, libuv, разница между готовностью callback и его фактическим выполнением. По отдельности объяснения были понятны. Но стоило закрыть видео, как знания снова превращались в набор слов — microtask, poll, process.nextTick, а объяснить, почему один callback выполнился раньше другого, уже не получалось.

Читать документацию по кругу не хотелось. Вместо этого автор сформулировал задачу для Codex.

Один промпт, из которого выросла лаборатория

Исходная постановка задачи выглядела так:

`` Занимаюсь изучением теории Node.js. Инициируй fullstack-проект, на котором я смогу запускать и наблюдать разные механизмы: демультиплексор событий, очередь callbacks, блокировку потока, Event Loop и другие темы. Сделай примеры с объяснениями в интерфейсе, чате и коде. Не знаю, как именно ты это реализуешь, но уверен, что хотя бы через логи порядок выполнения можно показать наглядно. ``

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

Это ещё не было глубоким учебным материалом, но исчезло главное трение процесса обучения: больше не нужно было каждый раз создавать новый файл, вспоминать команды запуска, расставлять console.log по коду и вручную сопоставлять вывод с текстом из документации. Достаточно открыть тему, нажать кнопку и посмотреть, что реально происходит.

Как шесть экспериментов превратились в 24 главы на двух языках

Первая версия закрывала только Node.js Runtime: порядок Event Loop, демультиплексор, очередь callbacks, блокировку основного потока, Worker Threads, пул потоков libuv и утечку памяти. Дальше автор начал добавлять в лабораторию всё, что изучал или встречал в реальной работе:

• Promises и BullMQ — очереди задач и асинхронные паттерны;
• closures и heap snapshots — работа с памятью и замыканиями;
• Prometheus и Grafana — мониторинг и метрики;
• Dependency Injection и жизненный цикл запроса в NestJS;
• микросервисы, PostgreSQL и инфраструктурные темы.

Ключевая идея — единый интерфейс, в котором можно быстро вернуться к теме, прочитать объяснение, открыть настоящий код, запустить эксперимент и увидеть фактический порядок событий, а не пересказ из чужой статьи. Runtime Lab не претендует на статус полноценного курса и не пытается заменить документацию. Это скорее личный тренажёр, который автор выложил в открытый доступ на случай, если он окажется полезен кому-то ещё.

Где такой подход ломается

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

Второй подводный камень — сам метод. Генерация прикладного кода агентом не заменяет чтение теории: без чёткого запроса на объяснение механики Codex просто соберёт рабочий CRUD, а понимание Event Loop так и останется набором разрозненных слов. Лаборатория работает только потому, что автор формулировал задачи на объяснение конкретных механизмов, а не на «сделай мне бэкенд».

Третий момент — риск подмены практики визуализацией. Наблюдать за таймлайном выполнения полезно, но это не заменяет реальную отладку продакшен-инцидента с ростом памяти или N+1-запросом под нагрузкой. Runtime Lab — это тренажёр для интуиции, а не симулятор боевых условий.

Что попробовать дальше

Если вы переходите из frontend в fullstack и застреваете на теории рантайма, тот же приём стоит повторить с любой темой, которая не укладывается в голове с первого раза: попросите агента не просто объяснить механизм, а собрать интерактивный стенд с логами, где видно фактический порядок событий. Начните с одной главы — например, только Event Loop и microtask-очереди — и расширяйте список тем по мере того, как они реально встречаются в работе, а не по чужому roadmap целиком. Такой подход превращает разовое изучение статьи в постоянно растущий личный справочник, к которому можно возвращаться месяцы спустя.

Источники

• Habr AI: 24 главы, два языка и живой Event Loop: как я собрал с Codex лабораторию по backend-разработке