Кодопись аналитика

76 179 строк кода за неделю. Ни одну из них я не читал.

Меня зовут Николай Щедрин, я ведущий аналитик Сбера. В этой статье продолжаю делиться инсайтами по использованию ИИ‑ассистентов в работе бизнес‑ и системного аналитика. Первую часть ^[1] я публиковал на Хабре в прошлом году.

Сегодня поговорим о разработке собственного проекта через описание требований в
.md‑файлах.

Предисловие

Чтобы оставаться в потоке стремительно меняющихся трендов и технологий, необходимо постоянно исследовать новые инструменты и подходы. Одним из таких исследований стало моё погружение в Vibe Coding с использованием инструментов GigaCode, Cursor, Claude Code, Kilo Code, Antigravity и других.

При выборе систем я ориентировался на наличие следующих возможностей:

• Agent mode — автономная работа над задачами;

• Rules — «прогрев» и фиксация контекста;

• MCP — подключение внешних источников контекста.

Режимы «Планировщик», «Архитектор» или поддержка Agents.md не были обязательными — их функциональность легко воспроизвести через Rules или кастомные правила. Хотя в некоторых решениях эта функциональность весьма удобна.

Даже Rules при необходимости можно эмулировать простым добавлением контекста в чат — именно так многие работали до середины 2024 года. Skills в рамках текущего исследования я пока не рассматриваю.

К разработке

Наблюдая за растущими объёмами контекста, с которым работают агенты, и, как следствие, за возрастающим количеством кода в ответах агентов, я всё чаще прихожу к мысли: сгенерированный ИИ код никто не будет читать. Например, мой личный рекорд — более 5 000 строк за одну сессию (15–20 минут работы агента). Чтобы вдумчиво прочитать и отрефакторить такой объём, потребуется несколько дней. Я задумался, возможно ли разработать насыщенные функциональностью рабочий продукт, вообще не просматривая код? Этот вопрос стал отправной точкой для моего погружения в Vibe Coding.

Я решил создать проект на языке, который мне абсолютно незнаком. Выбор пал на TypeScript.

Ещё в 2023 году у меня появилась идея создать ИИ‑ассистента для работы с онлайн‑редакторами в браузере. Знакомые разработчики предупреждали: задача сложная, а cost‑to‑value сомнительный.

В 2025 году на рынке появилась решение для объяснения кода в статьях. Идея показалась мне
классной. Поэтому первым шагом к полноценному браузерному ассистенту стало создание
расширения для Chromium‑браузеров с возможностью подключения к ИИ‑моделям и анализа
кода на страницах.

Подход к Vibe Coding

Я воспринимаю Vibe Coding как работу со стажёром или junior‑разработчиком:

• задачи должны быть максимально декомпозированы;

• формулировки — чёткими и измеримыми (желательно по SMART);

• ожидаемое поведение ^[2] — подробно описанным.

ИИ‑агент легко может «уплыть»: изменить рабочий код, сломать стили или потерять архитектурную логику ^[3]. Поэтому рекомендую начинать с инициализации Git‑репозитория. Я выбрал GitVerse — удобный и дружелюбный для новичков инструмент с интеграцией облачных (GigaStudio, GigaCode) и локальных (GigaCode plugin) ассистентов.

Правила разработки

Сначала я сформулировал базовые правила:

• Перед выполнением задачи анализировать .md‑файлы проекта (архитектура, требования,
  описание).

• Начинать изменения с проработки архитектуры. Наиболее экономной по токенам считаю
  чистую архитектуру ^[4]: агенту достаточно понимать 1–2 слоя вместо анализа всего проекта.

• Все изменения фиксировать в .md в человекочитаемом виде:

  • описание проекта;

  • архитектура;

  • требования;

  • тестирование.

• Соблюдать требования к Code Style.

• После каждой задачи запускать тесты и формировать отчёт в .md.

Если вы полностью делегируете агенту написание кода, то будьте готовы к тому, что не сможете читать его. Значит, вам критически важны артефакты в виде документации. Это естественный переход к Doc‑as‑Code: документация живёт рядом с кодом и усиливает как ИИ‑агентов, так и людей.

Самым удобным форматом для меня стали бизнес‑требования:

• use сase;

• функциональные требования;

• нефункциональные требования;

• пользователи;

• интегрируемые системы;

• …

Далее, через режим Plan (или прямым запросом) формирую To‑do list — и запускается
реализация.

После каждой задачи я:

1. проверял обновлённые .md‑файлы;

2. собирал проект;

3. загружал расширение в браузер;

4. тестировал инкремент.

Ошибки ^[5] копировал в чат ассистенту. Особенно полезным оказался режим Debug в Cursor — он лучше анализирует логи и системно исправляет ошибки.

Результат

Без знания TypeScript, но с энтузиазмом, за 1–2 недели вечерней работы удалось собрать
рабочее браузерное расширение со встроенным ИИ‑ассистентом.

Количество строк кода

Lite‑версия (open‑source) ^[6] (если ссылка не откроется, то попробуйте авторизоваться
на GitVerse):

• Определение блоков кода на страницах сайтов.

• Объяснение выбранного или выделенного кода.

• Подключение провайдеров моделей:

  • AI Factory (Cloud.ru ^[7]);

  • LM Studio;

  • OpenRouter;

  • OpenAI API.

• Голосовой ввод (Salute Speech API).

• Всплывающие и звуковые уведомления.

• Плавающая кнопка с Liquid Glass‑эффектом.

• Тёмная и светлая тема.

• Сохранение, редактирование и удаление диалогов.

• Сезонные анимации, привязанные к календарю.

Полная версия (alpha-версия выйдет под брендом GigaCode) уже добавляет к Lite:

• Подключение бесплатной корпоративной модели для кода.

• Стриминг ответов в чате.

• DevTools‑функции:

  • анализ Console;

  • анализ DOM;

  • анализ Network;

  • мониторинг производительности;

  • SEO‑оценка сайта.

• Inline code completion в популярных онлайн‑редакторах (Monaco, Ace и др.).

Примеры фичей

Выводы

Результат считаю показателем того, куда движется разработка: программы пишутся на человекочитаемом языке через .md‑файлы или иные форматы взаимодействия с агентом.

В голову приходит следующая аналогия:

• Низкоуровневые задачи → контроль, производительность, системное ПО — критичные
  по производительности компонентов или безопасности.

• Высокоуровневые задачи → бизнес‑приложения, веб, мобильные — менее требовательные к производительности компонентов.

• No‑code → быстрый запуск продуктов.

То есть, чем ниже требования к техническим ресурсам, стабильности приложения, безопасности и др., тем чаще мы можем уходить на уровень No‑code.

По итогам эксперимента, будущее разработки представляется таким:

• параллельно работают десятки агентов;

• код оптимизирован для понимания ИИ (структура, семантика, связи);

• минимизированы инфраструктурные потери (кеширование, сетевые задержки и др.);

• коммуникация с агентами происходит через привычные инструменты — сервисы корпоративной коммуникации, мессенджеры.

Я жду момента, когда задачи можно будет назначать background‑агентам через мессенджер и получать отчёт в удобном формате — без ручного участия в коде.

А вы?