# Codex вместо документации: как я собрал лабораторию по Node.js, пока учил Event Loop
Каноническая страница: https://plainews.ru/posts/codex-runtime-lab-nodejs-event-loop
Опубликовано: 2026-08-09T07:01:06.239Z

Разработчик собрал с Codex open-source лабораторию Runtime Lab на 24 главы про Event Loop, NestJS и Kafka — вот как один промпт превратился в учебный стенд.
Когда фронтендер переходит на бэкенд, первая ловушка — не синтаксис, а ощущение, что ты уже пишешь работающий код, но не понимаешь, что происходит под капотом. Разработчик 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-разработке