Разработка большой фичи с нуля часто начинается обманчиво легко. Заказчик объяснил идею, команда обсудила экраны, разработчики примерно представляют архитектуру. Можно приступать. Но стоит перейти от общего замысла к конкретному поведению, как появляются вопросы, на которые у каждого участника свой ответ.

Возьмём веб-систему бронирования общего оборудования. Сотрудник выбирает проектор и время, подтверждает бронь, при необходимости отменяет её. Звучит как несколько форм и CRUD. Иллюзия простоты исчезает, когда два человека одновременно бронируют один проектор, временный резерв зависает навсегда, а отменённая заявка продолжает занимать время в календаре.

Разберём, как пройти путь от такой идеи до реализации через LLM: сначала сделать правила видимыми, затем согласовать модель и контракты, после этого передавать агенту небольшие задачи. Это учебный пример, а не отчёт о внедрении или обещание определённого ускорения.

Нас двое. Один недавно искал работу и ходил по собеседованиям, второй сам собеседует кандидатов и раз за разом видит, как люди спотыкаются на одних и тех же задачах: debounce, глубокое сравнение объектов, форма с валидацией.

Готовиться к таким задачам на русском оказалось почти негде, особенно если вы пишете на JS или TS не только во фронте, но и на бэке. Поэтому мы сделали ПаровоJSик. Под катом рассказываем, что внутри, как тесты запускаются прямо в браузере и что будет дальше.