CODEX IT 
Тендеры и лиды
Информация
В прошлой статье мы рассказывали, почему IT-проекты часто срываются не из-за кода, а из-за отсутствия системы: спецификаций, архитектурных стандартов, контроля качества, управления изменениями и прозрачного процесса разработки.
Если коротко, эту систему мы внутри Codex IT называем CEF — Codex Engineering Framework.
Ссылка на статью: https://workspace.ru/blog/pochemu-it-proekty-sryvayutsya-delo-ne-tolko-v-kode/
В этом материале разберём более прикладную часть: как использовать искусственный интеллект и AI-агентов в разработке так, чтобы это действительно ускоряло работу команды, а не превращалось в хаотичное «напиши мне код».
Главная ошибка в использовании искусственного интеллекта — воспринимать его как продвинутую подсказку в редакторе.
На практике ИИ может намного больше.
Он умеет:
понимать контекст проекта;
искать связи между файлами;
объяснять чужой код;
рассуждать над архитектурой;
выполнять многошаговые задачи;
работать с логами;
помогать в отладке;
проводить ревью;
взаимодействовать с внешними сервисами;
запускать команды;
работать с браузером;
собирать контекст по большой кодовой базе.
Но качество результата зависит от двух вещей: насколько точно поставлена задача и насколько хороший контекст получил ИИ.
Если дать ему одну фразу «сделай авторизацию», результат будет случайным.
Если дать спецификацию, структуру проекта, пример похожей реализации и ограничения по стеку — результат будет намного ближе к тому, что нужно команде.
Одна из самых полезных задач для ИИ — быстро разобраться в незнакомом проекте.
В реальной разработке часто нужно не просто написать новый код, а понять, как уже устроена система:
где обрабатываются ошибки;
как работает авторизация;
где лежат роли пользователей;
как устроены API-методы;
как данные проходят от интерфейса до базы;
какой паттерн используется в похожем модуле.
Раньше разработчик тратил на это время вручную: открывал файлы, искал по проекту, читал реализацию, собирал картину в голове.
ИИ может сделать это быстрее.
Но важно не просто «закинуть весь проект» и ждать магии. Лучше давать задачу точнее.
Плохой запрос:
Посмотри проект и скажи, как тут всё работает.
Хороший запрос:
Вот структура проекта. Найди, где обрабатываются ошибки API, объясни паттерн и покажи, как сделать такую же обработку в новом модуле заказов.
Ещё пример:
Посмотри, как реализована авторизация в этом проекте. Мне нужно сделать аналогичный механизм для нового сервиса, но с ролями admin, manager и client. Сначала объясни текущую реализацию, потом предложи план переноса.
Так ИИ становится не генератором кода, а помощником в изучении проекта.
В хорошей инженерной системе команда не должна каждый раз решать одну и ту же задачу с нуля.
Если в одном проекте уже хорошо реализованы авторизация, работа с файлами, логирование, административная панель или обработка ошибок, эти решения можно переиспользовать.
ИИ здесь помогает быстро адаптировать готовый паттерн под новый контекст.
Например:
Посмотри, как в этом проекте реализована загрузка файлов в S3 через presigned URL. Сделай аналогичную реализацию в новом модуле документов, но с проверкой роли пользователя и ограничением по типу файла.
Или:
В этом проекте есть хороший паттерн repository/service/controller. Перенеси такой же подход в новый модуль заявок. Сначала покажи структуру файлов, потом реализуй базовые методы.
Такой подход особенно хорошо работает внутри CEF, потому что у команды уже есть стандартизированные шаблоны и проектные скелеты.
ИИ не придумывает решение с нуля, а помогает адаптировать проверенное.
AI-агент может работать не только с кодом, но и с окружением.
Например, он может подключаться к удалённой машине, выполнять команды, смотреть логи, проверять контейнеры и помогать с деплоем.
Типовые задачи:
посмотреть список Docker-контейнеров;
проверить статус сервиса;
получить последние логи;
перезапустить контейнер;
проверить переменные окружения;
найти ошибку в деплое;
проанализировать, почему сервис не поднялся.
Пример команды, которую агент может выполнить:
ssh user@server 'docker ps && docker logs app --tail=50'
Это удобно, когда нужно быстро разобраться с проблемой на сервере, не переключаясь между терминалом, логами и чатом.
Но здесь важно правило безопасности: ИИ не должен бесконтрольно выполнять критические действия на production-среде.
Для рабочих проектов лучше разделять права:
dev-стенды — можно давать больше свободы;
staging — ограниченный доступ;
production — только чтение логов и статусов, любые опасные действия через подтверждение человека.
ИИ должен ускорять инженера, а не становиться неконтролируемым администратором сервера.
Скилл — это заранее подготовленная инструкция для ИИ.
Вместо того чтобы каждый раз подробно объяснять, как проводить ревью, отладку или проверку перед деплоем, команда создаёт готовый сценарий.
Например:
/code-review — проверить код на ошибки, архитектуру, читаемость и безопасность;
/debug — разобрать ошибку по логам и предложить план исправления;
/testing-strategy — подготовить стратегию тестирования для новой функции;
/deploy-checklist — проверить готовность проекта к релизу;
/api-review — проверить API на безопасность, структуру и обработку ошибок;
/db-query-review — проверить запросы к базе данных на производительность.
Простой пример использования:
/code-review
Проверь изменения в модуле users.
Обрати внимание на права доступа, обработку ошибок и лишние запросы к базе данных.
Скиллы полезны тем, что сохраняют единый стандарт работы.
Если каждый разработчик по-разному просит ИИ сделать ревью, результат будет разный. Если команда использует общий скилл, проверка становится более предсказуемой.
В CEF это особенно важно: скиллы можно привязать к внутренним инженерным стандартам, чек-листам и правилам качества.
MCP — это способ подключить к ИИ внешние инструменты и сервисы.
Если говорить просто, MCP позволяет агенту работать не только с текстом в чате, но и с реальными источниками данных.
Например, можно подключить:
GitHub или GitLab;
Figma;
Notion;
Linear;
Slack;
базы данных;
браузер;
файловую систему;
внутреннюю документацию;
проектные шаблоны;
репозитории с готовыми решениями.
После этого ИИ может не ждать, пока человек скопирует данные вручную, а сам получить нужный контекст.
Например:
Открой макет в Figma, посмотри экран регистрации и сравни его с текущей реализацией в проекте. Найди расхождения по отступам, состояниям кнопок и текстам ошибок.
Или:
Найди в GitLab последний merge request по модулю payments, посмотри комментарии ревью и проверь, были ли исправлены замечания.
Или:
Открой задачу в Linear, найди связанный дизайн в Figma и подготовь план реализации.
Это сильно сокращает количество ручной работы.
Особенно важно, что через MCP можно подключать внутреннюю базу знаний. Тогда ИИ работает не как абстрактная модель из интернета, а как агент, который знает стандарты конкретной команды.
MCP-сервер есть не для всего. Но это не значит, что с инструментом нельзя работать через ИИ.
Альтернативный подход — дать агенту доступ к CLI и написать инструкцию в Markdown.
Например, можно создать файл:
# ai-instructions/docker.md
## Управление контейнерами
Для просмотра логов:
docker logs <container> --tail=100 -f
Для перезапуска:
docker restart <container>
Для проверки статуса:
docker ps -a
После этого ИИ может читать инструкцию и выполнять команды по правилам проекта.
Такой подход полезен для внутренних инструментов, самописных CLI, нестандартных сервисов и инфраструктурных сценариев.
Главное — не держать правила в голове у одного разработчика. Если инструмент используется регулярно, для него должна быть инструкция, которую может понять и человек, и AI-агент.
Воркдерево — это отдельная копия репозитория на отдельной ветке.
Для работы с AI-агентами это очень удобно.
Сценарий выглядит так:
Агент получает задачу.
Создаёт отдельную ветку и воркдерево.
Выполняет задачу изолированно.
Разработчик проверяет результат.
После ревью изменения переносятся в основную ветку.
Пример:
git worktree add ../feature-new-auth feature/new-auth
Зачем это нужно?
Во-первых, агент не ломает основную рабочую ветку.
Во-вторых, несколько агентов могут работать параллельно над разными задачами.
В-третьих, эксперимент легко удалить, если решение оказалось неудачным.
Это особенно полезно для задач, где непонятен результат:
рефакторинг;
оптимизация;
перенос модуля;
обновление зависимостей;
проверка альтернативной архитектуры;
исправление сложной ошибки.
ИИ можно дать пространство для работы, но не нужно давать ему возможность сразу менять основной код без контроля.
Для фронтенд-разработки важно не только написать код, но и увидеть, как он работает в браузере.
AI-агент с браузерным контекстом может:
открывать страницу;
делать скриншоты;
читать ошибки в консоли;
анализировать сетевые запросы;
кликать по элементам;
заполнять формы;
проверять поведение интерфейса;
запускать сценарии через Playwright.
Пример запроса:
Открой localhost:3000/dashboard, сделай скриншот и проверь, почему карточки разъехались на мобильной ширине. Посмотри консоль и сетевые запросы.
Или:
Пройди сценарий регистрации: открой страницу, введи тестовые данные, отправь форму и проверь, что пользователь попадает в личный кабинет.
Это превращает ИИ в помощника не только по коду, но и по проверке пользовательских сценариев.
Вместо того чтобы разработчик вручную описывал, что происходит на экране, агент может сам увидеть интерфейс, найти ошибку и предложить исправление.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13590 тендеров
проведено за восемь лет работы нашего сайта.
Один из лучших сценариев использования ИИ — отладка по логам.
Рабочий цикл выглядит так:
Запустили проект.
Получили ошибку.
Передали лог ИИ.
ИИ предложил причину и исправление.
Исправили.
Запустили снова.
Повторили цикл до исчезновения ошибки.
Источники логов:
docker logs <container> --tail=100
journalctl -u app -n 100
npm run dev
Также можно использовать:
консоль браузера;
network-запросы;
серверные логи;
логи CI/CD;
ошибки сборки;
сообщения базы данных.
Пример хорошего запроса:
Запустил контейнер, вот ошибка:
[ERROR] Cannot connect to database: ECONNREFUSED 127.1.1.1:5432
Проанализируй причину и предложи исправление конфигурации подключения.
Обычно 2–4 итерации с логами позволяют быстро найти причину.
Главное — не просить ИИ угадывать. Нужно давать ему факты: лог, конфигурацию, команду запуска и ожидаемое поведение.
ИИ не всегда предлагает оптимальный путь.
Он может:
переусложнить решение;
использовать лишнюю библиотеку;
не учесть архитектуру проекта;
предложить устаревший подход;
добавить лишний запрос к базе;
нарушить существующий паттерн;
решить задачу локально, но создать проблемы дальше.
Поэтому первое решение ИИ не нужно воспринимать как окончательное.
Его нужно уточнять.
Примеры полезных уточнений:
Не используй новую библиотеку. Сделай решение на текущем стеке проекта.
Это добавляет лишний запрос к базе данных. Переделай так, чтобы данные получались одним запросом.
В проекте используется паттерн service/repository. Перепиши решение в этой структуре.
Есть ли способ проще?
Покажи риски этого подхода.
Сравни два варианта реализации и объясни, какой лучше для нашего проекта.
ИИ хорошо работает, когда с ним ведут инженерный диалог. Не просто «сделай», а «объясни, сравни, упрости, проверь, переделай по стандарту».
Одно из недооценённых применений ИИ — обучение разработчиков.
ИИ может объяснять концепции на уровне конкретного человека и конкретного проекта.
Можно спрашивать:
Зачем здесь useCallback?
Почему этот индекс ускорит запрос?
Когда индексы вредят производительности?
Почему этот компонент перерендеривается?
Чем SSR отличается от CSR в нашем случае?
Почему здесь лучше использовать очередь, а не обычный синхронный вызов?
Главное — не просто принимать готовый код, а добиваться понимания.
Хороший запрос:
Ты добавил индекс на поле user_id.
Объясни, почему это ускорит запрос, в каких случаях индекс не поможет
и когда индексы могут ухудшить производительность.
Так ИИ перестаёт быть костылём и становится инструментом роста команды.
Контекстное окно — это объём информации, который ИИ держит в памяти в рамках одного диалога.
В него попадает всё:
код;
логи;
вопросы;
ответы;
файлы;
история обсуждения;
промежуточные решения.
Если контекст перегружен, качество ответов падает. Модель начинает терять детали, путаться в старых решениях и хуже фокусироваться на текущей задаче.
Поэтому важное правило: давать ИИ минимально необходимый контекст.
Плохой подход:
Вот весь src, исправь баг в users.service.ts.
Хороший подход:
Вот users.service.ts и users.repository.ts. Исправь баг в методе getById. Проблема: при несуществующем id возвращается 500, а должен быть 404.
Если задача маленькая — лучше новый чат и минимум файлов.
Если задача большая — нужно собрать только релевантные части проекта.
Если длинный диалог начал давать плохие ответы — лучше открыть новый чат и кратко пересказать суть.
В больших проектах разработчик не всегда знает, какие файлы нужны для задачи.
В этом случае можно делегировать сбор контекста суб-агенту.
Например:
Запусти суб-агента, который найдёт все места, где используется AuthService. Верни только релевантные файлы и краткое описание связей. Остальное не нужно.
Преимущество в том, что основной агент не получает весь проект целиком. Он получает уже очищенный и релевантный контекст.
Это экономит токены и повышает качество работы.
Суб-агентов можно запускать параллельно:
один ищет API-слой;
второй анализирует фронтенд;
третий проверяет базу данных;
четвёртый собирает связанные тесты.
После этого основной агент получает итоговую картину и решает задачу точнее.
Для разработки можно использовать разные AI-инструменты. У каждого есть своя сильная сторона.
Claude Code хорошо подходит для сложных инженерных задач:
анализ архитектуры;
работа с большими кодовыми базами;
агентные сценарии;
работа через терминал;
ревью сложного кода;
рефакторинг;
многошаговый дебаг;
работа с MCP;
использование суб-агентов и воркдеревьев.
Это хороший инструмент для задач, где нужно не просто быстро поправить строку, а разобраться в системе.
Cursor удобен для повседневной разработки внутри IDE.
Его сильные стороны:
быстрые правки прямо в файле;
inline-редактирование;
автодополнение;
понимание контекста проекта;
удобный чат рядом с кодом;
быстрый рефакторинг небольших участков.
Cursor особенно полезен для ежедневных задач: поправить компонент, дописать метод, быстро изменить структуру, сгенерировать типовой код.
Если не хочется использовать Cursor, можно работать через VS Code и AI-плагины.
Это даёт похожий сценарий: редактор остаётся привычным, а ИИ помогает с автодополнением, объяснением кода и быстрыми правками.
Условная логика такая:
ИИ ускоряет разработку, но не снимает ответственность с команды.
Нельзя просто принять любой результат, который предложила модель.
Важно соблюдать несколько правил:
не передавать секреты и ключи доступа в открытые чаты;
не давать агенту бесконтрольный доступ к production;
проверять изменения через ревью;
запускать тесты и автоматические проверки;
не мержить код без понимания, что именно изменилось;
не добавлять новые зависимости без причины;
не использовать решение, если оно ломает архитектуру проекта;
проверять безопасность API, доступы и работу с данными.
ИИ — это сильный инструмент, но финальная инженерная ответственность остаётся на человеке и команде.
В CEF искусственный интеллект встроен в процесс разработки не как отдельная модная надстройка, а как часть инженерной системы.
Он помогает на разных этапах:
ИИ анализирует требования, ищет пропущенные сценарии, помогает структурировать документацию и заранее выявляет риски.
ИИ помогает подобрать архитектурный подход, сравнить варианты реализации и найти похожие решения во внутренней базе знаний.
ИИ помогает работать с кодовой базой, переносить паттерны, генерировать типовой код, исправлять ошибки и ускорять повседневную работу.
ИИ используется для ревью сложных участков, анализа SQL и Prisma-запросов, поиска проблем производительности и проверки соответствия стандартам.
ИИ помогает работать с логами, контейнерами, браузером, CI/CD и серверным окружением.
ИИ помогает быстрее подключать новых разработчиков, объяснять существующую логику, анализировать изменения и снижать зависимость от отдельных специалистов.
ИИ в разработке — это не кнопка «сделать проект».
Это инструмент, который раскрывается только тогда, когда вокруг него есть система:
структурированная спецификация;
понятная архитектура;
стандарты качества;
шаблоны проектов;
внутренняя база знаний;
MCP-серверы;
скиллы;
воркдеревья;
ревью;
аудит;
контроль человека.
Без системы ИИ просто генерирует разрозненные ответы.
Внутри системы он становится ускорителем разработки.
Именно так мы используем AI-агентов в Codex IT: не вместо инженеров, а как часть инженерного процесса, который помогает быстрее разбираться в проектах, качественнее писать код, находить ошибки раньше и делать разработку более предсказуемой для бизнеса.
