Привет, Хабр! Меня зовут Максим Панфилов, я ИТ-предприниматель. Моя история в разработке началась 25 лет назад с программирования, но со временем переросла в управление собственной веб-студией. Последние лет 15 я не писал код, полностью переключившись на менеджмент и бизнес-процессы. Я думал, что мои дни в роли разработчика остались в прошлом, пока не случилась революция больших языковых моделей.

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

Главным инструментом, моим «костюмом Железного человека», стала среда разработки Warp. За последний год я перепробовал всё, где есть AI: Cursor, Windsurf, Replit и другие. Но именно Warp позволил мне в одиночку за два месяца полностью переписать и модернизировать сложный легаси-проект и довести до продакшна несколько новых.

В этой статье я хочу подробно рассказать, почему терминал в основе среды ИИ-разработки — это удобнее, чем текстовый редактор, как правильно «думать» вместе с LLM, и какие конкретные rules, MCP и фреймворки помогают мне в разработке, ускоряя её в разы.

Warp: среда разработки в терминале с ИИ

Большинство современных AI-инструментов, таких как Cursor или Windsurf – это форки IDE VS Code с панелью чата с ИИ: в их основе лежит текстовый редактор. Warp шел другим путем: изначально это был клиент для терминала, куда встроили ИИ.

По сути, команды терминала - это «шорткаты» для определенных действий, которые мы просим выполнять машину: то есть тоже язык. Но благодаря AI в терминале нет необходимости в том, чтобы запоминать «словарь» команд – LLM выступает переводчиком с естественного языка.

Режимы работы Warp

Процесс разработки так или иначе активно задействует терминал: сборка, git, ssh, docker, запуск скриптов, управление зависимостями. Warp не пытается изолировать вас от этого — он погружает вас в эту среду и усиливает ее.

Главная магия происходит в едином поле ввода. Оно легко переключается между двумя режимами:

1. Терминал: Для выполнения стандартных команд. Warp здесь предлагает умные автодополнения и запоминает часто используемые команды в контексте конкретных директорий проектов, что ускоряет работу: например, по какому адресу подключаться к серверу, как запустить проект, какие команды для git – достаточно нажать на клавиатуре стрелку вправо, и текст из подсказки заполнится в поле ввода.

2. AI-агент: Для общения с языковой моделью на естественном языке – в ответ на ваши промпты Warp будет писать код или выполнять команды в терминале. Если кому-то нравится надиктовывать текст, то есть возможность включить режим расшифровки аудио (я его отключил, мне удобнее печатать).

Warp достаточно умен, чтобы в большинстве случаев автоматически определять, что вы хотите. Начинаете вводить git push... — он понимает, что это команда. Пишете по-русски «объясни мне этот bash-скрипт» — он активирует AI. Это создает абсолютно бесшовный, непрерывный рабочий процесс, где AI — не отдельное окно, а естественное продолжение вашей командной строки. Есть удобный шорткат Cmd+I (на MacOS) для переключения между режимами.

При этом Warp состоит не только из командной строки – в интерфейсе можно открыть и файловый менеджер, и текстовый редактор (не такой крутой, как у подобий VS Code, но для того, чтобы поправить мелочи за ИИ хватает).

Warp как ваш личный DevOps

Одно из преимуществ Warp как терминала — его возможности не ограничиваются локальной машиной. После подключения по ssh Warp «прокидывает» своего агента на удаленный сервер — это называется "warpify session".

Это даёт возможность для автоматизации типовых DevOps-задач:

• Настройка Nginx: Добавь новый конфиг для домена example.com с проксированием на порт 3000 для проекта из папки /folder.

• Работа с Docker: Покажи логи контейнера 'my-app' за последний час и найди все ошибки.

• SSL-сертификаты: Выпусти и настрой Let's Encrypt сертификат для домена my-app.com.

AI видит файловую структуру сервера, может читать конфиги и выполнять команды. Для простых и средних проектов это практически полностью заменяет необходимость в отдельном DevOps-инженере.

Далее я расскажу про принципы, инструменты и методы разработки с использованием ИИ, к которым я пришел за последние полгода. В целом, их можно применять не только в Warp – это общие подходы, которые будут работать в любой среде разработки с LLM.

Context is king

Самое важное, что я осознал за время работы с AI в ��азработке: единственное, чем мы можем и должны управлять — это контекст. Качество работы любой модели напрямую зависит от того, насколько полный и релевантный контекст мы ей предоставляем. Все «агенты» и «инструменты разработки» по сути являются лишь продвинутыми менеджерами контекста для LLM. Вот несколько примеров, как можно управлять контекстом в Warp.

По сути весь промпт-инжиниринг и управление контекстом решают задачу направления и ограничения LLM при работе, чтобы она меньше выдумывала от себя, то есть галлюцинировала.

Контекст проекта – файл warp.md

Находясь в папке с кодом проекта достаточно выполнить команду /init, чтобы Warp проиндексировал кодовую базу и создал специальный файл warp.md. В нём содержится информация о стеке технологий, структуре директорий, основных зависимостях. Туда же вы можете добавить в него указания о своих архитектурных предпочтениях и другие моменты вашего код-стиля и принципов разработки для данного проекта – всё это LLM будет автоматически брать в контекст, когда вы будете ставить ей задачи.

Правила для кодинг-агента

Как и в других средах разработки с LLM, управлять поведением AI в Warp помогают настраиваемые правила – Rules. Вы можете задать как общие правила для всех своих проектов, так и специфические для каждого отдельного.

Поскольку я почти все пишу на Node.js и TypeScript, у меня есть глобальный набор правил под этот стек, которому агент следует всегда:

• Архитектура: Всегда использовать подходы SOLID и Clean Architecture при проектировании ��ешений.

• Типизация: В конце задачи проверять ошибки компиляции TypeScript, особенно в части строгой типизации.

• Комментарии: Обязательно оставлять инлайн-комментарии в коде. Это помогает не только мне быстрее разбираться в том, что он написал, но и самому AI, так как он использует эти комменты для лучшего понимания контекста при последующих задачах.

• Запреты (Deny List): У меня есть строгое правило никогда не трогать файл .env. Он может работать с .env.example, но рабочий .env ему трогать, удалять или редактировать запрещено.

• Согласование: Любые изменения, связанные со структурой базы данных, агент должен проводить только с моего согласования.

MCP Context7

Также есть возможность подключать внешние источники данных через MCP (Model Context Protocol). Самый главный из них для меня — это Context7, библиотека самой актуальной документации по десяткам тысяч фреймворков и библиотек, адаптированной для использования LLM.

Это критически важно, потому что модели, даже самые новые GPT-5 или Claude Sonnet 4.5, имеют «отсечку по знаниям» – их внутренняя «память» заканчивается на дате где-то за полгода до выпуска. Они могут не знать о выходе, например, Nuxt 4, и будут писать код по старым гайдам для Nuxt 2. Подключив в настройках MCP Context7, я просто добавляю в правила «всегда консультируйся с Context7», и агент идет в эту библиотеку за самой свежей документацией, что гарантирует использование актуальных версий и подходов.

Режим планирования и документация

Большие проекты, вроде полного рефакторинга кодовой базы или создания сложного веб-сервиса, нельзя выполнить одним промптом. Ключ к успеху — это Spec-Driven Development – разработка на основе спецификаций.

Мой обычный рабочий процесс над крупными задачами выглядит так:

1. Создание спецификации: Я начинаю с промпта-шортката: «Спроектируй...». Для AI это триггер, что нужно составить подробную документацию по функциональности, которую я описываю, и записать ее в .md файл в папку docs/.

2. Режим планирования: Для сложных задач Warp предлагает «режим планирования» (Planning). Я прошу AI составить пошаговый план внедрения (чек-лист) прямо в этом файле документации.

3. Контроль выполнения: Я даю команду: «Приступай к реализации по этому плану и отмечай прогресс в этом же файле по ходу выполнения».

Это помогает удерживать LLM в рамках контекста. Даже если AI «забивает» свое окно контекста и начинает новый диалог, он всегда может вернуться к файлу с документацией и отметкой прогресса, посмотреть, что уже сделано, а что нет, и продолжить работу ровно с того места, где остановился. Я же, как тимлид, просто проверяю этот docs/ файл и правлю спецификацию, если AI что-то понял не так, пока не согласую ее и не пущу в работу.

Контекст диалога

Когда вы ведете длинный диалог, контекстное окно модели начинает заполняться: в него попадают как ваши промпты и другие входные данные, так и ответы LLM и код, который она пишет. Окно контекста (context window) измеряется в тысячах токенов: например, 200 тысяч для Claude Sonnet или даже миллион для Gemini. Но при активной разработке на проектах с разветвленной архитектурой даже большое окно контекста заполняется. Тогда Warp незаметно для пользователя автоматически суммирует предыдущую беседу и уже эту выжимку использует как контекст, очищая контекстное окно, при этом сохраняя ключевую информацию из истории диалога.

Тем не менее, иногда качество ответов может ухудшаться, если контекст становится слишком большим. В таком случае можно попросить записать саммари по проделанной работе в отдельный md-файл, затем вручную начать новый диалог (есть шорткат Сmd+Shift+N) и передать весь необходимый контекст заново – "на чистую голову" модель может начать думать лучше, чем в перегруженном старом диалоге.

Ещё есть удобные функции дополнения контекста из результатов работы команд терминала:

• выделите любой текст в терминале – он автоматически добавится в контекст следующего промпта (над полем ввода появится плашка "selected text attached"),

• также в правом верхнем углу каждого блока с результатами работы команды терминала есть кнопка "Attach as Agent Mode context" – она добавляет в контекст,

• шорткат Cmd+↑ добавляет в контекст весь текст из результата последней команды терминала.

Скриншоты

При работе с фронтендом удобно просто копи-пастить скриншоты интерфейса в поле запроса – все модели в Warp мультимодальные, то есть могут обраб��тывать изображения. Это упрощает задачу, когда нужно показать, как выглядит текущий UI, который нужно поправить, или передать сложную схему, не тратя время на ее словесное описание.

Выбор языковой модели

В Warp доступны все ключевые на текущий момент языковые модели, за исключением OpenAI Codex и моделей Grok.

Какие выводы я сделал по использованию языковых моделей (актуально на ноябрь 2025 года):

• Claude 4.5 Haiku: У меня установлена в настройках по умолчанию. Для быстрых, простых задач: внести небольшую правку, объяснить фрагмент кода, выполнить команду в терминале. Самая быстрая и дешевая.

• GPT-5 High Reasoning: Мой основной выбор для сложных архитектурных задач. Рефакторинг, проектирование новых модулей, анализ взаимосвязей в большой кодовой базе. На моем опыте, именно GPT-5 лучше всех справляется с удержанием «в уме» сложной, многоуровневой логики и работой с документацией.

• Claude 4.5 Sonnet: Тоже подходит для сложных задач. Не так эффективно, как GPT-5, зато быстрее. Главное отличие – использует emoji в ответах!

• Claude 4.5 Sonnet (thinking): Вариант флагманской модели от Claude с размышлениями. Это главный конкурент GPT-5 High Reasoning в моём списке. Думает быстрее и часто хорошо справляется, но всё же даю ему второе место.

• Gemini 2.5: Идеален для работы с текстом, когда нужен копирайтинг, но с кодом он справляется хуже GPT или Claude, даже несмотря на заявленное окно контекста в 1 миллион токенов.

На сложных задачах я всегда выбираю GPT-5 High Reasoning: на ключевом проекте, о котором я расскажу ниже, у меня было несколько моментов, когда я решил поэкспериментировать и доверил задачи сложного рефакторинга модулей Claude Sonnet и Gemini – обе модели ушли не туда, и пришлось откатывать изменения. С GPT-5 я успешно завершил задуманное.

Кейс: воскрешение из легаси-ада за два месяца

Чтобы не быть голословным, расскажу о реальной задаче. Мой пет-проект «OK, Bob!» — трекер задач в Telegram с мини-аппом и веб-версией — за несколько лет превратился в монстра. Он состоял из трех разных репозиториев (бек на Nest.js, фронт на Vue.js и бот на Telegraf.js), написанных в разное время разными разработчиками. И если фронт мы успели отрефакторить, то кодовая база бека страдала от всех известных болезней: спагетти-код, отсутствие единого стиля, устаревшие зависимости, три разные версии API, работающие одновременно. Развивать это было болью, а пользовательская база росла, и мне хотелось продолжать улучшать продукт.

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

Шаг 1: Аудит и планирование

Первое, что я сделал — попросил AI стать моим архитектором и отревьювить код модуль за модулем. Базово начинал с команды:

Проведи аудит модуля src/module/users. Используя документацию из context-7 по Nest.js и принципы Clean Architecture, составь подробный план рефакторинга.

В результате я получал подробный Markdown-документ, который содержал:

• Цели и задачи рефакторинга

• Предложенная новая файловая структура модуля

• Детальный пошаговый план работ, разбитый на этапы

• Описанные риски и критерии приемки

Такой подход к разработке с AI называется Spec-Driven Development или «разработка, основанная на спецификации». И это единственный способ, которым можно справляться с сложными задачами, требующими тщательного планирования и архитектуры.

Шаг 2: Итеративная реализация

Далее я работал итерациями, давая команды вида:

Приступай к реализации этапа 1 из файла docs/users/refactoring_plan.md. Отмечай прогресс по ходу выполнения в этом же файле.

AI начинал писать код, а я выступал в роли ревьюера: в warp можно установить режим «автоприёмки», но это не всегда подходит, особенно если задача сложная. По умолчанию все изменения в файлах нужно согласовывать: если что-то не устраивает, можно отредактировать вручную или дать уточняющие инструкции для LLM.

Шаг 3: Автотесты

Разработка проекта с множеством взаимосвязей внутри кодовой базы требует тщательного подхода к тестированию. С помощью LLM удобно писать unit-тесты для бекенда. Для моей задачи я также сделал покрытие e2e-тестами для сравнения идентичности работы старых и новых методов API, которые были написаны с ИИ.

Сейчас на проекте более 700 автотестов. Они стали моей страховкой и позволили проводить рефакторинг с уверенностью, что я ничего не сломал.

Результат

Чуть больше, чем за два месяца я получил:

• Единый репозиторий для бекенда и бота, без необходимости их связки через API

• Архитектуру модулей, построенную на принципах Clean Architecture: изоляция логики, разделение на сервисы, контроллеры, репозитории для взаимодействия с базой данных, валидаторы, DTO, интерфейсы и абстракции

• Оптимизированное взаимодействие между модулями (вместо медленных API-вызовов между сервисами теперь это внутренние вызовы через порты)

• Полное покрытие кода тестами

На этой основе уже можно было продолжать развивать продукт. Добавление новых функций пошло гораздо проще: за несколько недель я запустил новую систему per-seat тарификации, прикрутил GPT в бота для постановки задач, закрыл старые баги, ну и в целом подчистил накопившийся беклог. Сейчас работать с проектом одно удовольствие, а скорость релизов возрасла в разы.

Фреймворки – ещё один способ управлять контекстом

Напомню, что одна из главных задач применяющего ИИ разработчика – минимизировать галлюцинации LLM. Поэтому для проектов, которые я начинаю с нуля, я использую фреймворки и инструменты, которые хорошо поддаются инструкциям и имеют четкую структуру. Это еще один отличный способ задать рамки при работе с ИИ.

Next.js

Недавно попалась на глаза статья Dead Framework Theory про то, что React – это уже не фреймворк, а платформа. Все LLM-ассистенты по дефолту генерят код на React – просто потому, что на нем написано 80% веба, на котором они учились. Поэтому Next.js – сейчас очевидный выбор, чтобы выжать из AI-агентов максимум при разработке веб-сервисов (особенно, если нужен SSR).

Payload CMS

Но под Next.js нужна админка для бека. Тут после энного количества экспериментов я остановился на Payload CMS – максимально гибкой и простой для быстрого запуска. Вот основные преимущества:

• Конфигурация в коде (Code-First): Схема данных, коллекции и конфигурация описываются кодом на TypeScript. Это обеспечивает версионирование и строгую типизацию.

• Автоматические миграции: Встроенные инструменты для генерации и управления миграциями базы данных через CLI упрощают ��зменение схемы данных.

• Встроенный ORM: Payload использует Drizzle ORM для работы с БД, предоставляя удобный и типизированный доступ к данным. ORM – это абстракция над базой данных, которая упрощает взаимодействие и делает код более предсказуемым и безопасным.

• REST и GraphQL API из коробки: Система автоматически генерирует REST и GraphQL API на основе схемы данных.

• Система хуков (Hooks): Позволяет встраивать собственную логику событий на разных этапах жизненного цикла документов (до и после сохранения, удаления, чтения).

• Расширяемая админ-панель на React: Админ-панель построена на React и полностью кастомизируется. Можно добавлять собственные React-компоненты для полей, представлений или целых страниц.

• Гибкая аутентификация и контроль доступа: Встроенная система аутентификации и гранулярного контроля доступа на уровне полей и операций (CRUD), которую можно расширять и адаптировать.

• Полная поддержка TypeScript: Обеспечивает строгую типизацию во всей системе, от конфигурации до API, помогая отлавливать ошибки на этапе разработки.

• Live Preview и Hot Reload: Позволяет видеть изменения контента в реальном времени на фронтенде и обеспечивает мгновенное обновление при разработке без перезагрузки сервера.

Shadcn Blocks

Для быстрого запуска фронтенда я открыл для себя ShadcnBlocks (на базе Shadcn UI). Это не просто библиотека компонентов, а набор готовых, стилизованных блоков (шаблонов).

Мой воркфлоу: я захожу в каталог блоков, выбираю подходящий (например, «Hero Section»), копирую код и вставляю его в Warp с инструкцией: «Сделай мне раздел на странице на основе этого кода, контент возьми отсюда». Не нужно верстать с нуля, при этом кастомизация с помощью Tailwind CSS ничем не ограничена.

Так, например, я сделал сайт для нового направления своего бизнеса, связанного с внедрением GenAI – panfilov.consulting.

Refine: Мой выбор для админок и внутренних инструментов

В какой-то момент мне понадобилось быстро создать простую, но функциональную админку для управления кейсами студии. Мои поиски привели меня к Refine. Это оказался идеальный инструмент для таких задач: это фреймворк на базе React, специально созданный для быстрой сборки админ-панелей, дашбордов и внутренних инструментов.

Что меня в нем привлекло:

• Агностицизм к UI-фреймворкам: встроенная поддержка популярных библиотек, таких как Material UI, Ant Design, Chakra UI, Mantine, а также возможность использовать любой собственный дизайн или TailwindCSS.

• Автогенерация CRUD-интерфейсов: можно автоматически создавать CRUD-страницы на основе структуры данных.

• Встроенные компоненты: Refine идет с огромным количеством готовых решений. Например, в нем уже встроена авторизация (включая логин через Яндекс, который привязывается очень просто), управление правами доступа и ролями (администратор, менеджер), инвайты и так далее.

• Интеграция с данными: БД на PostgreSQL, подключение к S3-хранилищу для файлов и CDN для их раздачи.

В итоге из внутреннего инструмента для управления кейсами студии я запилил ещё один пет-проект: я прикрутил ИИ для сбора инфы по кейсам, сделал лендинг на Payload CMS – и получилась «Кейс-Платформа», ИИ-ассистент и админка для управления кейсами.

Выводы

Возвращение в разработку после 15-летнего перерыва могло стать болезненным опытом, но благодаря инструментам вроде Warp оно превратилось в увлекательное приключение. Это не просто ускорение работы – это фундаментальное изменение парадигмы. AI становится вашим напарником, младшим разработчиком, архитектором и DevOps-специалистом в одном лице.

Вы перестаете тратить время на рутину, синтаксис и boilerplate, и концентрируетесь на самом важном — на архитектуре, логике и продукте. Если вы давно не кодили или чувствуете, что «заржавели» — сейчас лучшее время, чтобы вернуться. Ваши сверхспособности уже ждут вас.

Я не написал про ценообразование Warp, потому что как раз сейчас они его меняют и я еще не разобрался с новой тарифной сеткой. Единственное, что могу сказать: в предыдущей конфигурации тариф Lightspeed за $225 в месяц отбился у меня минимум х10, а скорее всего – х100. За 20 тысяч рублей в месяц я мог бы купить максимум 10-15 часов работы middle разработчика. С Warp же я получил результат, эквивалентный трудозатратам команды с бюджетом в несколько миллионов рублей.

Общие рекомендации по работе с LLM

• Управляйте контекстом. Качество работы модели напрямую зависит от полноты и релевантности предоставленной информации. Используйте все возможности для его уточнения: файлы с описанием проекта (warp.md), настраиваемые правила (Rules), внешние базы знаний (MCP Context7) и даже скриншоты для задач по фронтенду.

• Используйте разработку через спецификации (Spec-Driven Development). Для больших задач не пытайтесь всё сделать одним промптом. Сначала попросите AI составить подробный план и документацию, согласуйте их, и только потом приступайте к пошаговой реализации.

• Выбирайте модель под задачу. Экспериментируйте и подбирайте оптимальный вариант: используйте быстрые и дешевые модели (Claude Haiku) для простых правок, а мощные и «думающие» (GPT-5 High Reasoning) — для сложного рефакторинга и проектирования архитектуры.

• «Заземляйте» модель с помощью фреймворков. Инструменты с четкой структурой (Next.js, Payload CMS, Refine) и ORM задают рамки, в которых AI работает более предсказуемо и меньше галлюцинирует.

• Делегируйте, но контролируйте. Выступайте в роли архитектора или тимлида. Делегируйте AI рутину и написание boilerplate-кода, но всегда проводите ревью и не используйте «авто-приёмку» для сложных задач.

• Пишите автотесты. Это ваша страховка при рефакторинге и разработке. Попросите AI помочь с написанием unit- и e2e-тестов, чтобы быть уверенным, что новые изменения ничего не сломали.

Спасибо за внимание! Если было интересно меня читать, ещё я делюсь опытом у себя в Telegram-канале и всегда готов обсудить с вами вопросы там или здесь в комментариях.