Долгое DevRel общался с разработчиками, писал статьи, делал митапы, помогал разобраться в платформе. Чем лучше разработчик понимал архитектуру, тем меньше было ошибок в интеграциях и тем быстрее запускались решения.
Но с появлением AI-ассистентов меняется сам процесс работы с платформой. Разработчик больше не начинает с изучения API. Он описывает задачу, а модель собирает решение по документации и примерам.
Рассмотрим, как меняется роль DevRel в этих условиях.
Как AI меняет разработку
Раньше разработчик начинал с интерфейсов. Он изучал модели данных, ограничения, продумывал структуру решения и собирал логику шаг за шагом.
Теперь отправная точка — задача. Инженер описывает, что нужно получить на выходе, а AI собирает решение по документации и примерам. Но стоит понимать, что модель не «понимает» продукт и работает только с тем, что явно прописано. Если сценарии описаны расплывчато или допускают разные трактовки, результат будет таким же.
Меняется и сам способ разработки. Вместо того чтобы вручную проектировать код и править его построчно, разработчик меняет описание задачи и получает новую версию решения от модели. Если результат не подходит, он уточняет запрос — добавляет детали, ограничения, условия — и AI предлагает обновлённый вариант. Исправления происходят на уровне формулировки задачи, а не через поиск конкретной строки в коде.
В такой модели любой пробел в документации быстро становится массовым шаблоном. AI выбирает самый простой способ и начинает повторять его снова и снова, из-за чего ошибки распространяются по экосистеме быстрее, чем их успевают исправить.
Две аудитории DevRel и одна задача
DevRel работает с двумя типами разработчиков внутри экосистемы.
Первая аудитория — создатели маркетплейс-приложений массового продукта. Им важно быстро вывести решение и показать практическую ценность. Платформу они часто используют точечно — через примеры, шаблоны и готовые куски кода. Глубоко разбираться в устройстве системы обычно нет ни времени, ни желания. Главное — запуститься и начать зарабатывать.
Вторая аудитория — внутренние разработчики компаний-клиентов B2B-платформы. Они строят интеграции и автоматизации под конкретные бизнес-процессы. Платформа для них — один из инструментов в общей IT-системе компании. В приоритете — чтобы процесс работал стабильно.
Контекст разный, поведение похожее. Обе аудитории работают со множеством сценариев, имеют разный уровень подготовки и ориентированы прежде всего на результат.
Отсюда и общая задача DevRel — сократить количество альтернативных способов использования платформы и закрепить понятные правила работы с ней. Для типовой интеграции должен быть один понятный и рекомендуемый способ реализации — с чётким набором методов и примеров. Если вариантов несколько, AI выберет самый простой — и именно он станет массовым, даже если в долгосрочной перспективе он создаёт проблемы.
Классический DevRel больше не справляется
Документацию сегодня читают как справочник. Нужно вызвать метод — открыли страницу метода. Нужно понять формат поля — посмотрели пример.
В итоге интеграция складывается из отдельных примеров и методов, найденных в документации или подсказанных AI. Решение работает, но не всегда учитывает реальные ограничения системы: лимиты, порядок вызовов, зависимости между сущностями.
Примеры кода становятся фактическим стандартом. Если в документации показан один способ создать сделку или обновить контакт, именно его и копируют. Даже если он упрощённый, не учитывает пограничные случаи или написан «для наглядности». Через какое-то время этот пример начинает жить своей жизнью — его можно встретить в десятках приложений.
AI ускоряет распространение таких паттернов. Модель берёт опубликованный пример и воспроизводит его снова и снова. Если в нём есть неточность, она масштабируется автоматически. Один неудачный способ работы с API превращается в массовую практику.
Команда DevRel может написать статью с разбором ошибок или провести вебинар, но это не меняет уже скопированный код. Коммуникация догоняет проблему, а не предотвращает её.
Практическая DevRel-стратегия в эпоху AI
В нашей практике DevRel, помимо традиционных активностей, занимается как раз задачами, которые в перспективе должны помогать моделям правильнее создавать решения для:
● системного сбора фидбека от дев-сообществ, чтобы находить проблемные сценарии, включения этого фидбека в цикл улучшений продукта или улучшения документации;
● разработки и развития boilerplates для разработчиков, SDK для разных языков, UI Kit, стартеров приложений с готовыми skills и инструкциями для AI-агентов;
● проектирования новых сценариев интеграции в продукте.
Сегодня DevRel уже не может ограничиваться обучением разработчиков. Теперь необходимо сделать так, чтобы платформой было сложно пользоваться неправильно, даже если код генерирует AI. Документация должна быть однозначной, примеры — отражать реальную практику, а методы — не оставлять пространства для двусмысленности.
Поэтому DevRel всё чаще работает внутри продуктовой команды. Он участвует в проектировании API, анализирует, как на практике строятся интеграции, какие ошибки повторяются, где разработчики обходят ограничения системы. На основе этого пересматриваются методы, упрощаются типовые решения и убираются лишние альтернативы. Речь идёт не о количестве контента, а о том, чтобы платформа вела себя предсказуемо.
Меняются и метрики. Важно не сколько статей опубликовано и сколько людей пришло на митап, а насколько стабильно работают интеграции, как часто повторяются одни и те же ошибки и может ли AI собрать рабочее решение без ручной доработки. Если типовые задачи решаются одинаково и без обходных путей, значит платформа готова к автономной разработке. В такой модели DevRel отвечает уже не за коммуникацию, а за устойчивость экосистемы.
