Введение

Эта статья — результат практического эксперимента по использованию AI-агента Claude Code (модель Claude Opus 4.5) для разработки на платформе 1С:Предприятие. Мы выполнили две реальные задачи разной сложности и оценили результаты с помощью профессионального 1С-разработчика.

Главный вывод: AI-ассистент — отличный аналитик и документатор для 1С, но ненадёжный кодер. Анализ, декомпозиция и документирование — во много раз быстрее человека. Принятие решений и код — оставить разработчику.

Выполненные задачи

Задача 1: Обработка «Поиск партии по товарам»

Суть задачи: Создать обработку для УПП 1.2, которая помогает складским сотрудникам идентифицировать неопознанный груз по списку товаров.

Требования:

• Форма с выбором складов и таблицей товаров (номенклатура + характеристика + количество)
• Поиск документов «Поступление товаров и услуг» где ВСЕ указанные товары есть на остатках в одной партии
• Вывод результата через СКД с двумя уровнями группировки
• Условное оформление (зелёный фон при совпадении, жирный шрифт для введённых позиций)

Результат: Готовый BSL-код на 814 строк + инструкция по созданию формы в конфигураторе.

Задача 2: Анализ обработки интеграции с CyberLines

Суть задачи: Проанализировать существующую обработку загрузки заявок на перевозку (13,378 строк кода) и ответить на 5 вопросов.

Требовалось:

1. Описать способы активации обработки
2. Спланировать внедрение многопоточности и отказоустойчивости
3. Предложить оптимизацию SQL-запросов
4. Составить список данных из внешней системы vs окружения 1С
5. Описать поэтапный процесс создания заявки

Результат: Детальный аналитический отчёт на 660 строк + отчёт линтера на 497 строк + исправленная версия обработки (0 синтаксических ошибок, но с логическими проблемами).

Хронология: с какой попытки успех?

Задача 1: «Поиск партии по товарам» — успех с 3-й итерации

Время от старта до рабочего решения: 6 дней (с учётом пауз на ревью)

Ключевой перелом: Подключение MCP-сервера для валидации API платформы.

Задача 2: «Анализ обработки CyberLines» — успех с 1-й итерации

Время: ~2 часа на анализ 13,378 строк + генерацию отчётов + автоисправление

Почему анализ сразу успех: Аналитическая задача — AI читает код, а не пишет. Формат вывода (Markdown) стандартный.

Почему код с ошибками: AI делает синтаксически корректные, но логически неверные изменения — ломает запросы и транзакции.

Сводка по задачам

Процесс работы

Проблема 1: Проприетарный формат 1С

Первый барьер — файл .dt (дамп базы данных 1С). Это закрытый бинарный формат, который ни один AI прочитать не может.

Решение: 1С-разработчик выгрузил конфигурацию в файлы (XML + BSL) через стандартную процедуру конфигуратора. Это критический шаг — без выгруженных исходников работа невозможна.

«Это считай sql бекап с кашей из символов внутри» — Никита (1С-разработчик)

Итерации по задаче 1

Итерация 1: 14 критических замечаний от эксперта:

• Неверный формат вывода (чистый код вместо XML-структуры форм)
• Выбор товаров через табличную часть вместо списка значений
• Изобретение велосипедов вместо использования встроенных методов
• Использование несуществующих функций (СТРОКАСОЕДИНИТЬ — выдумка)
• Несоответствие ТЗ по использованию СКД

Итерация 2: После загрузки замечаний — улучшения, но:

• XML-файлы для загрузки в 1С не работают (ошибки XDTO)
• СКД используется частично
• Часть ошибок не исправлена

Итерация 3 (с MCP): Подключили MCP-сервер для API платформы 1С:

• Код стал осмысленнее
• Логических косяков не обнаружено
• Штрихкоды формируются правильно

«Я бы даже сказал что это можно решением считать» — Никита

Оценка от эксперта: код (задача 1)

После финальной итерации:

«Из хороших новостей он победил проблему с штрихкодами, теперь они верно формироваться будут. Код явно стал осмысленней. Каких-то жестких логических косяков не вижу.»

Замечания, которые остались:

• БСП (Библиотека стандартных подсистем) не используется
• СКД используется минимально, хотя просили полностью на нём

Оценка от эксперта: анализ (задача 2, вопросы 1–5)

Развёрнутая оценка ответов на 5 аналитических вопросов:

Оценка от эксперта: автоисправление кода (задача 2)

AI получил обработку на 13,378 строк и самостоятельно внёс исправления. Результат проверки экспертом:

«Шок, но синтаксических ошибок 0… Но с запросами как всегда у нейронки тяжко. Написан синтаксически верно, но нарушил их логику» — Никита

Инструменты

1. Claude Code

AI-агент в командной строке с доступом к файловой системе.

Ссылка: claude.ai/code

Модель: Claude Opus 4.5 (claude-opus-4-5-20251101)

Преимущества для 1С:

• Может читать и анализировать большие BSL-файлы (13,000+ строк)
• Понимает структуру конфигурации 1С (XML + BSL)
• Хорошо справляется с аналитическими задачами

2. MCP 1C Platform

MCP-сервер для поиска по API платформы 1С:Предприятие.

Ссылка: github.com/alkoleft/mcp-bsl-platform-context

Возможности:

• Поиск методов, свойств и типов платформы
• Получение конструкторов типов
• Информация о членах типов (методы, свойства)

Пример использования:

● 1c-platform - search (MCP)(query: "Метаданные", type: "property")
  ⎿ "# Результаты поиска: 'Метаданные'
     **Тип:** `ОбъектМетаданныхКонфигурация`
     **Только для чтения:** Да"

● 1c-platform - search (MCP)(query: "РегистрНакопления", type: "type")
  ⎿ "## Найдено 6 элементов
     ### РегистрНакопленияВыборка.<Имя регистра накопления>
     **Тип элемента:** Type"

Установка MCP-сервера в Claude Code:

1. Убедитесь, что установлен Node.js 18+:

node --version  # v18.0.0 или выше

2. Откройте настройки Claude Code:

# Windows
notepad %USERPROFILE%\.claude\settings.json

# macOS/Linux
nano ~/.claude/settings.json

3. Добавьте конфигурацию MCP-сервера:

{
  "mcpServers": {
    "1c-platform": {
      "command": "npx",
      "args": ["mcp-bsl-platform-context"]
    }
  }
}

4. Перезапустите Claude Code для применения настроек.
5. Проверьте работу — при запуске Claude Code должен показать:

MCP Servers: 1c-platform

Альтернативная установка (локально):

# Клонировать репозиторий
git clone https://github.com/alkoleft/mcp-bsl-platform-context.git
cd mcp-bsl-platform-context

# Установить зависимости
npm install

# Настроить в settings.json
{
  "mcpServers": {
    "1c-platform": {
      "command": "node",
      "args": ["/полный/путь/к/mcp-bsl-platform-context/dist/index.js"]
    }
  }
}

Доступные методы MCP:

3. BSL Language Server (Линтер)

Статический анализатор кода для языка 1С.

Репозиторий: github.com/1c-syntax/bsl-language-server

Скачать: Releases — файл bsl-language-server-X.X.X-exec.jar

Версия в эксперименте: 0.28.3

Требования: Java 17+ (скачать с adoptium.net)

Установка:

# 1. Скачать JAR-файл
curl -L -o bsl-language-server.jar \
  https://github.com/1c-syntax/bsl-language-server/releases/download/v0.28.3/bsl-language-server-0.28.3-exec.jar

# 2. Проверить версию Java
java -version  # Нужна 17+

# 3. Проверить работу
java -jar bsl-language-server.jar --version

Команды для анализа:

# Анализ одного файла
java -jar bsl-language-server.jar --analyze --src ./path/to/file.bsl

# Анализ директории с выводом в JSON
java -jar bsl-language-server.jar --analyze --src ./path/to/folder \
  --reporter json --outputDir ./reports

# Анализ с конфигурацией (отключение определённых правил)
java -jar bsl-language-server.jar --analyze --src ./path/to/folder \
  --configuration ./.bslls.json

Пример .bslls.json для отключения правил:

{
  "diagnostics": {
    "parameters": {
      "Typo": false,
      "SpaceAtStartComment": false
    }
  }
}

Возможности:

• Проверка синтаксиса и стандартов 1С
• Поиск ошибок транзакций (PairingBrokenTransaction, CommitTransactionOutsideTryCatch)
• Выявление устаревших методов (DeprecatedCurrentDate)
• Оценка когнитивной и цикломатической сложности
• Поиск неиспользуемых переменных

Статистика по анализу обработки (13,378 строк):

Топ найденных ошибок:

• VirtualTableCallWithoutParameters (12 шт.) — вызов виртуальной таблицы без параметров
• IncorrectUseOfStrTemplate (10 шт.) — некорректное использование СтрШаблон()
• PairingBrokenTransaction (7 шт.) — нарушена парность транзакций
• DeprecatedCurrentDate (5 шт.) — использование устаревшей ТекущаяДата()

Что получилось хорошо

1. Анализ существующего кода

Claude Code отлично справляется с анализом больших кодовых баз:

• Нашёл все ключевые способы активации обработки и правильно расписал их применение (хотя пропустил возможности запуска для отладки с формы)
• Описал механизм многопоточности через ДлительныеОперации.ВыполнитьВФоне()
• Составил список из 12 хранимых процедур SQL с их назначением и расположением в коде
• Построил диаграмму последовательности создания заявки

«Учитывая как он в файлах хорошо покапался и нашел нужные регистры и документы, думаю просто план реализации от нейронки был бы очень полезен» — Никита

2. Понимание существующей функциональности

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

«Ответ подробно расписал что есть в обработке, структурировал информацию и даже номера строк прикрепил. Уверен если бы я был незнаком с обработкой, то мне такая информация очень помогла бы. Плюс для составления документации очень полезно» — Никита

3. Структурирование SQL-запросов

Особенно впечатлил разбор SQL-запросов. В реальных 1С-проектах поиск нужного запроса — это боль: огромная вложенность процедур, имена таблиц отличаются от стандартных 1С-объектов, новые разработчики тратят часы, чтобы разобраться.

AI сразу расписал где какой запрос находится. Рекомендации по оптимизации тоже оценены положительно.

«Нереальный респект за структурирование и подробное описание. Помню боль при разработке, как приходилось искать нужный запрос и как новые люди в проекте могли часы тратить… а тут он сразу расписал где какой запрос» — Никита

Единственное пожелание — не хватило ожидаемого прироста производительности по каждой рекомендации.

4. Обнаружение забытых настроек

При составлении списка данных из внешней системы AI нашёл «Критичные настройки из ПВХ» — план видов характеристик. Эта информация не запрашивалась напрямую, но AI самостоятельно извлёк настройки, включая пару, о которых разработчик уже забыл.

«Из плюсов выдал «Критичные настройки из ПВХ». Изначально даже не задумывался над их получением с такой формулировкой задачи, но он их достал и нашел даже пару настроек о которых я уже успел забыть, но они действительно используются» — Никита

5. Поиск регистров и документов

По ТЗ AI самостоятельно определил:

• Документ поступления: Документ.ПоступлениеТоваровУслуг
• Регистр партий: РегистрНакопления.ПартииТоваровНаСкладах
• Регистр штрихкодов: РегистрСведений.ШтрихкодыНоменклатуры

6. Структурирование отчётов

Создание документации с:

• Таблицами сравнения
• ASCII-диаграммами архитектуры
• Группировкой ошибок по типам
• Приоритизацией исправлений
• Наглядными схемами процессов

7. Работа с линтером

Интеграция BSL Language Server позволила:

• Автоматически находить ошибки транзакций
• Выявлять устаревшие методы (ТекущаяДата() → ТекущаяДатаСеанса())
• Оценивать когнитивную сложность методов

8. Синтаксическая корректность исправлений

При автоматическом исправлении обработки (13,378 строк) — ноль синтаксических ошибок. AI корректно:

• Переписал код согласно стандартам 1С
• Самостоятельно нашёл и обновил версию обработки

Что получилось плохо

1. Создание форм

AI не может генерировать валидный XML для управляемых форм 1С. Ошибки XDTO при попытке загрузить в конфигуратор.

Решение: Генерировать только BSL-код + инструкцию для ручного создания формы.

2. Использование БСП

AI не знает методы Библиотеки стандартных подсистем:

• Использует ПоказатьПредупреждение() вместо ОбщегоНазначенияКлиентСервер.СообщитьПользователю()
• Не применяет типовые паттерны БСП

3. Выдуманные функции

В первых итерациях AI изобретал несуществующие методы:

• СТРОКАСОЕДИНИТЬ (в 1С такого нет)
• Неверные сигнатуры методов СКД

Решение: MCP-сервер для валидации API.

4. Множество итераций

Для получения рабочего результата потребовалось 3+ итерации с участием эксперта.

5. Нарушение логики запросов при автоисправлении

При попытке оптимизировать SQL-запросы AI написал синтаксически корректный код, но нарушил логику выборки данных — результат запроса возвращал бы другие данные, что повлекло бы ошибки в бизнес-процессе.

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

6. Нарушение логики транзакций

AI переписал логику объявления и фиксации транзакций. Результат — документы, которые раньше записывались, теперь могут не записаться.

«Зачем-то переписал логику объявления и фиксации транзакций. Выглядит так, как будто логика записи документов нарушена и мы теперь не запишем то что раньше бы записалось» — Никита

7. Избыточное логирование

AI добавил логирование всех исключений — хорошая идея в теории, но непрактичная для обработки с десятками миллионов документов. Хранить такой объём логов просто негде.

8. Поверхностность глубокого анализа

При описании данных из внешней системы AI дал правильную, но недостаточно глубокую информацию. Например, описал «Files» просто как «Файлы взвешивания» вместо того, чтобы раскрыть структуру получаемых таблиц с типизацией полей.

Процесс создания заявки описан верхнеуровнево: заполнение табличных частей (3000+ строк кода с нелинейной логикой, множеством условий и созданием новых объектов БД) объединено в один этап. Инициализация данных — основа обработки — описана в 10 строк, хотя данные получаются из нескольких мест внешней системы, соединяются с данными из 1С, создаются новые элементы.

«Процесс описан правильно, даже наглядные схемы нарисованы. Но процесс описан верхнеуровнево. Заполнение табличных частей — это 3000 строк кода минимум и сам процесс не линейный» — Никита

Сравнение с Cursor

Для чистоты эксперимента эксперт попробовал ту же задачу через Cursor:

«Ради интереса попробовал через курсор сделать эту задачу. Из плюсов он смог нормально сформировать файлы для загрузки в 1С, но из минусов там полный бред. Если в твоей версии хотя-бы чувствовалась логика и верный курс действий, то в моей всё намного хуже, вообще не по ТЗ, ошибки через строку»

Вывод: Claude Code показал лучшее понимание задачи, хотя и с ошибками в реализации.

Рекомендации по настройке

CLAUDE.md для 1С-проектов

# Правила для 1С разработки

## Язык
- Используй русские названия переменных и методов
- Следуй стандартам 1С по именованию (ПаскальКейс)

## Форматы
- НЕ генерируй XML-файлы форм — они не будут работать
- Генерируй BSL-код + инструкцию для создания формы вручную

## API
- ВСЕГДА используй MCP 1c-platform для проверки существования методов
- НЕ выдумывай функции платформы

## БСП
- Приоритет методам из БСП когда они доступны
- ОбщегоНазначенияКлиентСервер.СообщитьПользователю() вместо ПоказатьПредупреждение()

## Линтер
- Прогоняй код через BSL Language Server перед финализацией
- Обязательно исправляй ошибки уровня Error

Настройка MCP

{
  "mcpServers": {
    "1c-platform": {
      "command": "npx",
      "args": ["mcp-bsl-platform-context"]
    }
  }
}

Итоговые выводы

Вердикт эксперта

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

«Использовать как помощник для анализа, декомпозиции, написания документации, советов по ревью и рефакторингу — можно спокойно, она может очень помочь и подобные задачи во много раз быстрее человека выполнить и может даже лучше. Но принятие решений и код лучше оставить разработчику — тут будет быстрее и надежнее, имея описание от нейронки, сделать всё руками» — Никита

Для чего Claude Code подходит в 1С:

Для чего НЕ подходит:

Главный вывод

Ресурсы

Статья основана на реальном эксперименте, январь-февраль 2026

Участники: Денис Матаков , Клементьев Никита (Эксперт, 1С-разработчик )

Работа с Claude Code требует некоторой дисциплины. Если правильно выстроить процесс, можно получить качественный результат и при этом экономить лимиты. Ниже я описал основные шаги, которые использую сам.

1. Подготовка репозитория: README

Первое, что необходимо сделать в новом проекте, — попросить Claude сгенерировать README.md. Но не в «человеческом» понимании, где много описаний, картинок и диаграмм, а в утилитарном виде:

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

Формулировать запрос стоит максимально чётко: «Напиши краткий README, который ты будешь использовать для дальнейшей работы над новыми фичами». Такой файл избавит от лишних затрат токенов при повторных обращениях.

2. Правила и лучшие практики: CLAUDE.md

Следующий шаг — формирование файла CLAUDE.md. Это набор правил и ограничений, которые Claude будет учитывать при каждом промпте. Важно, чтобы файл был компактным: каждая строка попадает в контекст при запросах.

Создать его можно реверс-промптингом: попросить Claude сгенерировать правила, затем сократить их, сохранив суть.

Пример:

# CLAUDE.md - Project Rules & Guidelines

## CRITICAL RULES
- Read all .md files before starting work
- NO git push without explicit permission
- NO modifying/deleting tests without permission
- NO touching files not mentioned in requests

## KISS & DRY Principles
- Keep it simple — aim for <50 lines when possible
- Reuse existing code, don't reinvent
- No over-engineering or unnecessary abstractions

## DEVELOPMENT WORKFLOW
- Use English only
- Follow existing patterns and conventions
- Run tests before commits
- Keep files under 500 lines

Полная версия может быть длиннее, но её нужно оптимизировать до десятков строк, а не сотен.

3. Управление контекстом: /clear

При начале работы над новой фичей рекомендуется очищать контекст командой:

/clear

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

4. Работа с небольшими доработками

Для простых задач последовательность такова:

1. Очистить контекст.
2. Сослаться на README.md и CLAUDE.md.
3. Сформулировать задачу: «Используя информацию из файлов, сделай доработку X».
4. Начать с небольшой фичи, проверить стиль мышления Claude.

Важно проверять код: Claude иногда пытается обойти проблему и создаёт новые методы или файлы, которые не нужны. Если повторяется ошибка — добавить новое правило в CLAUDE.md.

5. Работа с крупными задачами и продуктами

Если доработка крупная или это создание нового продукта, то подход похожий, но в README.md вместо структуры проекта кладётся план разработки.

Или файл можно назвать, например, feature.md. Туда помещается детальный пошаговый план реализации: задачи, чек-листы, тесты, коммиты.

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

6. Общие рекомендации

• Не расслабляться. Claude может сломать уже рабочий код.
• Тесты критичны. Каждая фича должна быть покрыта тестами.
• Фиксировать рабочие состояния. Делать коммиты после успешных шагов, чтобы всегда можно было откатиться.
• Не бояться перезапусков. Если зашли в тупик, лучше очистить контекст, переформулировать задачу, сделать реверт до рабочего состояния и начать заново.

Так выстраивается базовая методология работы с Claude Code: минимизация лишнего контекста, формализация правил и строгая дисциплина коммитов.

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

1. Вступление: команда и цель спринта

Слайды:

• Название команды и даты спринта.
• Роли (PO, BA, BE, FE, QA, MOB, Design) и укомплектованность.
• Цель спринта (1–2 предложения, не «сделать задачи», а «проверить гипотезу/закрыть потребность/улучшить метрику»).

Совет: цель должна быть связана с ценностью для бизнеса или пользователя.

2. Контекст и метрики

Слайды:

• Ключевые продуктовые метрики: DAU/MAU, CSI, рост/падение.
• Изменения по сравнению с прошлым периодом (стрелки или график).

Совет: акцентируй внимание не на цифрах ради цифр, а на том, как текущая работа помогает улучшать метрики.

3. Задачи спринта

Слайды:

• Список инициатив, которые брали в работу.
• Подпись «Цель → Решение → Эффект».

Совет: выделяй не технические детали («сделали API»), а пользовательские сценарии («появилась возможность объединять документы по признаку»).

4. Проблема и решение

Слайды (для каждой инициативы):

• Проблема, которую решали (коротко, в 1–2 предложениях).
• Решение (что сделали).
• Бизнес-эффект (зачем это ценно, что меняется для пользователя или компании).
• Скриншоты/видео-демонстрация функционала.

Совет:
Каждый кусок функционала показывай через призму «Было — Стало». Это сразу даёт ощущение прогресса.

5. Демонстрация

Слайды:

• Скринкаст или живой показ интерфейса.
• Подписи «вот так пользователь взаимодействует», «вот что изменилось».

Совет: всегда рассказывай через user story: «Пользователь заходит → делает действие → получает результат».

6. Обсуждение и вопросы

Слайды:

• Заготовленный «Discussion» с контактами PO.
• Место для обратной связи.

Совет:

• Заверши вопросом: «Что для вас ценно в этом изменении?», а не «Есть вопросы?». Это стимулирует осмысленную обратную связь.

Как оформить

• Минимум текста — тезисы, не абзацы. Всё объясняешь голосом.
• Скрины вместо слов — если есть интерфейс, обязательно показать.
• Цветовые акценты — выделяй «проблема/решение/эффект».
• Графики вместо цифр — тренд лучше воспринимается, чем таблица.

Основные акценты демо

1. Не рассказывай «что делали» → показывай «какую ценность создали».
2. Не уходи в детали реализации, если это не тех. демо.
3. Старайся, чтобы каждый участник понял: «Это реально улучшает продукт / процессы / жизнь пользователя».

Что это и чем отличается от привычных ассистентов в IDE

Claude Code — не «ещё одна вкладка» в редакторе, а консольное приложение. Это одновременно минус и плюс. Минус — меньше «визуального» взаимодействия: не выделишь мышкой фрагмент, не перетащишь картинку. Плюс — независимость от конкретной IDE и даже от графической ОС: можно подключаться к любому серверу и работать через терминал с файлами, коммитами и проверками в реальном времени. Для конфигов на сервере это особенно удобно: формулируешь задачу по-человечески — получаешь результат, не ковыряясь в Vim или nano. 

Полевая проверка: смешанный репозиторий (Flutter + Python)

Для пробы взял проект, где в одном репозитории живут мобильное приложение на Flutter и бэкенд на Python. За 1–2 часа фокусной работы начал закрывать накопившиеся баги, причём результаты оказались стабильнее, чем в Cursor. В Cursor часто теряется контекст и появляются неконсистентные правки; здесь же запросы выполнялись предсказуемее, а изменения были компактными: по 10–20 строк на фичу — без «простыней» на тысячи строк. 

Управление качеством: гайдлайны и «claude.md»

Ключевой вывод: ассистент хорошо следует заданным правилам. Я собрал существующие гайдлайны из проекта, добавил то, что посчитал важным, и положил в отдельный файл (условный claude.md). После этого фичи «приземлялись» в код корректно и короткими диффами. Однако архитектурные решения за вас он не примет: местами проскакивают «джуновские» огрехи на уровне архитектуры. Значит, схема работы такая: мы заранее фиксируем архитектуру и гайдлайны, а ассистент ускоряет рутину в рамках заданных рамок. 

Лимиты и экономика тарифа

Неожиданный момент — скорость, с которой уходит лимит. На базовом тарифе за $20 я упёрся в ограничения примерно за пару часов, после чего нужно ждать окна обновления лимитов (до двух часов). При таком темпе реальнее смотреть на план за $100, а если нагрузка выше — и на $200. И всё же это оправдано, если сравнивать со стоимостью рабочего времени: при хорошем использовании Claude Code закрывает объём задач уровня strong junior / middle с высокой скоростью. 

Где прирост максимальный

Самый приятный эффект — снижение стресса за счёт делегирования «мелочёвки»: подвинуть кнопку, подправить отступы, найти нужное место в коде и подсказать корректный фикс. Это те самые задачи, которые «съедают» время и внимание, но не требуют сложной архитектурной проработки. По ощущениям, прирост продуктивности — 20–40% в зависимости от типа задач и дисциплины в формулировке запросов. 

Интеграция с JetBrains и командное применение

У нас часть команды сидит в JetBrains, где Cursor недоступен. Консольный формат Claude Code решает эту проблему: через плагин его можно использовать и в JetBrains-средах, и в терминале на серверах. Внедрение для команды вижу так: определить набор правил (архитектура, стили, соглашения), описать их в claude.md, выбрать подходящий тариф (вероятнее $100) и договориться о «ритуалах» использования — когда просим ассистента, как проверяем результат и кто несёт ответственность за итоги. 

Итоги

Claude Code понравился предсказуемостью и уважением к гайдлайнам, а также универсальностью консольного формата. Сдерживает только лимит базового плана: для продуктивной ежедневной работы его маловато. Следующий шаг — ещё одна сессия, после которой окончательно зафиксирую тариф и запущу эксперимент в проде для команды JetBrains. Если результат сохранится, это станет стандартным инструментом для рутинных правок и точечных фич. 

P.S. Если резюмировать одним предложением: Claude Code — это быстрый «мидл» в консоли, который не спорит с вашими гайдлайнами и закрывает рутину, пока вы занимаетесь архитектурой. 

Что важно включить в адаптивный плейбук?

• Спринты и ритуалы. Определяем продолжительность, частоту встреч и четкое расписание: планирование, ежедневные стендапы, ревью, ретро.
• Метрики ценности. Фокус не на закрытых задачах, а на том, сколько пользы получает клиент.
• Автономность команд. Полномочия + ответственность = скорость без микроменеджмента.
• Прозрачность. Общий календарь релизов, открытые доски задач, видимые цели.
• Устойчивая скорость. Откажитесь от «геройских» овертаймов — выигрыш в долгую даёт именно стабильный темп.
• Постоянное улучшение. Каждая ретроспектива — не отчёт о неудачах, а план апгрейда процессов.
• Живая документация. 24-страничный плейбук должен обновляться по эволюции команды, а не пылиться в Wiki.

Итог: пока не настроены процессы, CTO остаётся лишь «тушить пожары». Плейбук превращает хаос в систему: ценность поставляется регулярно, а команда развивается предсказуемо.

Готов поделиться своим шаблоном адаптивного плейбука — бери, кастомизируй и внедряй!

Заказать консультацию CTO — https://mtkv.ru

#CTO #ITруководство #Процессы #Scrum #Плейбук

Эта статья отвечает на важные вопросы, которые возникают, когда ты впервые сталкиваешься с MCP:

• Что именно он делает?
• Чем он отличается от API?
• Как модель узнаёт, какие инструменты есть?
• Где лежат адреса, авторизация и прочее?
• Можно ли через MCP совершать не только запросы, но и действия?

MCP на пальцах: таблица-пример

Для начала — суть в одной таблице:

Что делает MCP на самом деле

С технической точки зрения, MCP — это протокол общения между LLM и внешними источниками данных или действиями. Он описывает, как модель может:

• обратиться к SQL-базе;
• извлечь файл;
• вызвать API;
• отправить сообщение;
• выполнить код;
• и даже скомбинировать несколько действий последовательно.

Главная идея: модель не знает, как устроен внешний мир, но умеет формировать запросы в едином формате, а MCP-сервер знает, как их обработать и что вернуть обратно.

MCP — это не просто API

Сразу возникает логичный вопрос: а чем MCP отличается от обычного API?

Ответ: уровнем абстракции.

Обычный API — это конкретная реализация с конкретной документацией.

MCP — это унифицированный способ описания и исполнения любых API. Вся магия MCP в том, что:

1. Модель видит инструмент как «псевдофункцию» с описанием.
2. MCP-сервер сам знает, как эту функцию реализовать.
3. Протокол позволяет строить последовательности действий (например, “спроси в базе — потом построй график”).

А как модель знает, какие есть инструменты?

Модель не «знает» заранее. При старте сессии или при подключении плагина ей передаётся так называемый Tool Manifest — описание всех доступных инструментов. Обычно это JSON, в котором указано:

• название инструмента (send_sms, sql_query);
• описание;
• параметры и их типы.

Пример:

{

  «name»: «send_sms»,

  «description»: «Sends an SMS to the specified phone number»,

  «parameters»: {

    «number»: «string»,

    «text»: «string»

  }

}

Модель читает этот список и потом сама решает, какой инструмент использовать и какие параметры подставить.

А как она узнаёт, где находится MCP-сервер?

Вот тут кроется то, чего пока не хватает в большинстве реализаций: механизма подключения MCP-серверов.

У OpenAI есть .well-known/ai-plugin.json. У Anthropic — tool-use manifest. У LangChain — ToolLoader.

У MCP должен быть публичный манифест MCP-сервера, в котором указано:

• mcp_url — куда слать запросы;
• auth — какая авторизация нужна (Bearer, API Key, OAuth);
• tools_manifest_url — где взять список инструментов.

То есть подключение MCP-сервера должно выглядеть примерно так:

{

  «name»: «Internal Tools MCP»,

  «mcp_url»: «https://mcp.mycompany.com/api»,

  «auth»: {

    «type»: «bearer»,

    «token»: «sk-xyz»

  },

  «tools_manifest_url»: «https://mcp.mycompany.com/api/tools»

}

Пока нет единого глобального репозитория MCP-серверов, но такая идея витает в воздухе — и обязательно появится.

А можно ли через MCP не просто получать данные, а делать что-то?

Да. И это один из самых важных и недооценённых аспектов.

Пример — отправка СМС. Модель не знает, что такое Twilio, какие там нужны ключи, заголовки и URL. Она просто вызывает send_sms с нужными параметрами. А дальше:

1. MCP-сервер подставляет токен.
2. Отправляет POST-запрос на нужный адрес.
3. Возвращает модели { «status»: «sent» }.

Модель как бы управляет миром — через интерфейс MCP.

Вывод

MCP — это мост между языковой моделью и реальным миром.

Он не заменяет API, он делает их доступными, понятными и управляемыми для моделей. MCP позволяет строить LLM-агентов, которые не просто болтают, а действуют, получают доступ к данным, комбинируют инструменты и работают в рамках заданной архитектуры.

Если раньше вы ограничивались ответами из головы модели — теперь можно подключить к ней всё, что у вас есть: от баз до внешних сервисов, от PDF до внутренних CRM. И всё это — в едином протоколе.

И вот что я понял из такого долгосрочного программирования…

Умные, но забывчивые

Современные копайлот-ассистенты — это не команда, а стажёры. Они пишут быстро, но:

• забывают, что делали в предыдущем файле;
• не держат в голове структуру проекта;
• путаются, если вы перескакиваете между фронтом, мобилкой и бэком.

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

Всё начинается с чек-листа

Первое, что нужно сделать, — попросить AI составить подробный пошаговый план, как будет строиться ваш проект. Это и есть дорожная карта.

• Я делал 5 больших этапов.
• Внутри каждого — маленькие подпункты.
• Но этого мало — детализация нужна больше, особенно в логических блоках: frontend, backend, auth, UI…

README + prompt.md — ваш инструмент памяти

После каждого логического блока (например, вы закончили backend) — просите AI:

1. Прочитать весь код.
2. Составить README: что, где, зачем.
3. Написать prompt.md — инструкцию самому себе. Как бы «если забудешь, чем ты тут занимался — прочитай это».

Это не шутка: именно такую стратегию используют в Cursor, но делают это автоматически и примитивно. А вы — осознанно.

Изоляция и Domain Driven Design

Каждый логический модуль — как отдельная зона ответственности:

• Пишите отдельный README и prompt для каждого микросервиса.
• Когда вы начинаете новый чат с AI — просто закиньте ему нужный README.
• При необходимости — добавьте фразу «think deep». Особенно хорошо работает с Gemini 2.5 Pro — он включается.

Android Studio и localhost — не лучшие друзья

Когда я впервые запускал API с Android Studio, был неприятно удивлён:

• localhost не работает.
• Нужно использовать 10.0.2.2, чтобы обращаться к хосту.

Это поломало мой initial setup. Решение: не использовать локальные адреса вовсе, а поднять stage-сервер и слать запросы туда.

Кто круче всех из копайлот-ассистентов?

Мой субъективный рейтинг:

1. Gemini 2.5 Pro

• Хорошо работает с prompt.md
• Умеет думать «внутри файла»
• Послушный, не навязчивый

2. ChatGPT 4.1

• Очень осторожный
• Часто спрашивает, но даёт хорошие архитектурные идеи

3. Claude 3.5 Sonnet

• Включает AutoRun
• Может начать писать новую кодовую базу, не спросив
• Оставляет за собой кучу лишних файлов

Дёшево — значит ограниченно

• Cursor и GitHub Copilot — дешёвые ($20/мес).
• Но у них очень маленький контекст — они быстро всё забывают.
• Claude Code (Anthropic) — дорогой, сложный в получении, но реально помнит.

Если вы делаете MVP — научитесь работать с дешевыми инструментами и пишите документацию. Это ваш единственный способ сохранить мышление AI в фокусе.

Резюме

Если вы делаете приложение с AI:

• Разбивайте на логические блоки.
• Пишите README и prompt.md после каждого.
• Обновляйте их после доработок.
• Не верьте в “память” копайлота — её просто нет.
• Используйте “think deep” в нужный момент.

И тогда даже с дешевыми инструментами можно собрать что-то большое, логичное и рабочее.

Команды становятся всё более интернациональными — участники говорят на английском, русском, французском, испанском и даже китайском. Но как провести созвон, если не все владеют одним общим языком? Удивительно, но Google Meet уже умеет помогать в таких ситуациях: автоматически распознавать речь и переводить её в субтитры.

Звучит как магия, и — спойлер — работает это действительно хорошо. Особенно если на встрече используется два языка. Когда больше — потребуется чуть больше внимания к настройке, но и это вполне реально.

Что нужно для работы

Google Meet умеет автоперевод только в платных версиях (Google Workspace Business/Enterprise). Также потребуется:

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

Как устроен перевод в Meet

Всё держится на двух настройках, которые каждый участник выставляет самостоятельно:

1. Spoken language — язык, на котором говорит спикер.
2. Translation language — язык, на который переводятся субтитры для вас.

Google Meet не понимает автоматически, кто говорит на каком языке. Поэтому, если на встрече, например, один говорит по-русски, а другой — по-английски, каждому нужно вручную указать: «я слушаю русскую речь, переводи мне её на английский» — и наоборот.

Как это работает на практике

Допустим, в митинге участвуют два человека: Анна говорит по-русски, Джон — по-английски.

• Анна ставит: Spoken language — English, Translation — Russian
• Джон ставит: Spoken language — Russian, Translation — English

Результат: каждый видит переведённые субтитры, когда другой говорит. Общение становится комфортным, и никаких переводчиков не нужно.

Где включить настройки

1. Зайти в Google Meet.
2. Внизу нажать на «⋮» → Settings → вкладка Captions.
3. Включить Live Captions.
4. Установить:
   • Spoken language — язык спикера.
   • Translation language — язык, на который нужен перевод.

Субтитры появятся автоматически.

В чём подвох?

Функция перевода работает лучше всего при двух языках. Как только добавляется третий — начинается путаница: ведь Meet не может определить, кто говорит на каком языке, и участникам придётся постоянно менять настройки вручную.

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

Какие языки поддерживаются

На апрель 2025 года Google Meet поддерживает перевод речи в субтитрах для следующих языков:

• Английский
• Русский
• Испанский
• Французский
• Немецкий
• Итальянский
• Португальский
• Японский
• Корейский
• Китайский (упрощённый и традиционный)

Некоторые из этих языков работают только как «язык речи» или только как «язык перевода» — нужно проверять на тестовой встрече. Но также появилось много новый языков в статусе BETA, так что есть шанс, что и необходимый вам язык там тоже присутствует!

Советы напоследок

• Проведите тестовый созвон хотя бы с двумя участниками — чтобы отладить настройку.
• Добавьте короткую инструкцию в приглашение (особенно если в команде кто-то не очень техничный).
• Закрепите правило: каждый сам отвечает за свои субтитры и язык перевода.

Если всё сделать правильно — Google Meet становится отличным инструментом для международных встреч. Работает стабильно, не требует стороннего ПО и, по сути, заменяет синхронного переводчика для простых рабочих задач.

В этой статье:

• Что такое эпоха
• Как понять, что модель переобучается
• Сколько эпох нужно
• Как выбрать и настроить обучение правильно

Что такое эпоха

Эпоха — это один полный проход по всему обучающему набору данных.

Допустим, у вас есть 10 000 примеров, и вы обучаете модель с batch_size=100. Это значит, за одну эпоху модель увидит все примеры по 100 штук за раз — всего 100 шагов.

Когда эпох несколько, модель повторно видит одни и те же данные, чтобы «отточить» предсказания.

Почему не всегда больше — лучше

Модель может начать запоминать примеры, а не учиться на них обобщать. Это называется переобучение.

Признаки:

• Ошибка на обучении (train loss) продолжает падать
• Ошибка на валидации (val loss) начинает расти
• Точность на тренировке высокая, на тесте — низкая

Как отслеживать переобучение

1. Делите данные на train и validation
2. После каждой эпохи измеряйте val loss и метрику (например, accuracy)
3. Стройте графики

Если val loss начинает расти — модель начала переобучаться, даже если train loss ещё падает.

Сколько эпох выбрать

Ответ: зависит от данных, модели и задачи. Но есть ориентиры:

• Маленькие датасеты → 5–20 эпох
• Большие датасеты → 2–5 эпох (модель быстро учится)

Что помогает:

• Early stopping — остановка, когда val loss не улучшается 2–3 эпохи
• Checkpoints — сохранять лучшую модель по val metric

Пример с EarlyStopping

from transformers import TrainerCallback

class EarlyStop(TrainerCallback):
    def __init__(self, patience=3):
        self.patience = patience
        self.counter = 0
        self.best_loss = float("inf")

    def on_evaluate(self, args, state, control, metrics, **kwargs):
        val_loss = metrics.get("eval_loss")
        if val_loss < self.best_loss:
            self.best_loss = val_loss
            self.counter = 0
        else:
            self.counter += 1
        if self.counter >= self.patience:
            control.should_training_stop = True

Вывод

Обучение — это баланс. Слишком мало эпох — модель не научится. Слишком много — начнёт переобучаться.

Следите за метриками на валидации, сохраняйте лучшие версии и не бойтесь остановиться чуть раньше — это часто даёт лучший результат.

В этой статье:

• Что такое квантование
• Какие есть методы: GPTQ, GGUF, QLoRA
• Чем они отличаются
• Когда и как их применять

Что такое квантование

Квантование — это перевод весов модели из 32-битного формата (float32) в более компактные форматы: float16, int8, int4 и т. д.

Цель:

• уменьшить размер модели (в 2–8 раз)
• сократить использование VRAM
• ускорить инференс

Пример: модель в fp32 весит 13 ГБ, а в int4 — 3–4 ГБ.

GPTQ: для ускоренного инференса

GPTQ — это метод постобученного квантования, при котором веса модели переводятся в int4 или int8 после завершения обучения.

Плюсы:

• Уменьшает размер модели до 4–8 раз
• Поддерживается в text-generation-webui, AutoGPTQ, ExLlama
• Работает на GPU без необходимости обучения

Минусы:

• Квантованная модель не обучается повторно (read-only)

Пример:

from auto_gptq import AutoGPTQForCausalLM
model = AutoGPTQForCausalLM.from_quantized("model-gptq", device_map="auto")

GGUF: для запуска на CPU и llama.cpp

GGUF — это специальный формат, разработанный для llama.cpp и совместимых проектов (KoboldCpp, LM Studio, Ollama).

Плюсы:

• Отлично работает на CPU (в том числе MacBook, ARM, Raspberry Pi)
• Минимальные требования по памяти
• Поддерживает quantized модели 2–8 бит
• Быстрый старт без установки PyTorch

Минусы:

• Не обучается
• Нужен отдельный toolchain для подготовки моделей (конвертация из HF формата)

QLoRA: обучение моделей в 4-битном формате

QLoRA (Quantized Low-Rank Adapter) — это способ дообучать большие модели, используя 4-битное квантование и адаптеры.

Плюсы:

• Можно дообучать 7B/13B модели даже на 24ГБ GPU
• Поддерживает LoRA: сохраняются только адаптеры (100–200 МБ)
• Обучается быстро и эффективно

Минусы:

• Нужно сохранить и базовую модель, и адаптеры
• Инференс требует загрузки 4bit модели + PEFT адаптера

Сравнение методов

Когда использовать что

• GPTQ: если нужно быстро запустить большую модель на GPU без обучения
• GGUF: если хотите использовать модель на ноутбуке или сервере без GPU
• QLoRA: если нужно дообучить LLM под свои данные без больших ресурсов

Вывод

Квантование делает использование LLM доступным даже для разработчиков с одним GPU или обычным ПК. Выбор метода зависит от цели: запуск, обучение или интеграция в прод. Все три метода — важные инструменты в арсенале инженера, работающего с языковыми моделями.