Почему миллион токенов не гарантирует, что AI поймет ваш проект? 🧠

Развитие LLM долго измеряли цифрами: больше параметров, контекста и прочих составляющих. Особенно впечатляюще выглядит рост контекстных окон. Кажется логичным: если модель способна принять больше информации, значит, ей можно показать практически весь проект и проблема понимания контекста исчезнет. Но в реальной разработке все сложнее.

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

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

Хороший оркестратор не пытается передать модели все. Он помогает передать ей нужное: проект, файлы, документацию, репозиторий, инструменты и результаты предыдущих шагов. Потому что настоящий контекст — это не количество токенов, это способность системы понимать, какая информация имеет значение для конкретной задачи. 🧘‍♀️

Что произойдет, если AI перестанет быть инструментом для написания кода? 🤔

На протяжении нескольких лет AI в разработке ассоциировался прежде всего с генерацией кода. Автодополнение, написание функций, рефакторинг — именно эти сценарии стали первым массовым применением LLM среди разработчиков. Но сегодня область применения гораздо шире. IBM описывает использование AI на различных этапах SDLC: от сбора требований и проектирования до разработки, тестирования, поддержки и документации. Gartner также отмечает, что AI-ассистенты постепенно выходят за рамки простой генерации и дополнения кода. И это меняет саму роль AI.

Если модель используется только для генерации функции, достаточно хорошего ассистента. Но если она участвует в нескольких этапах, возникает уже другая задача: как связать эти действия между собой?

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

Получается, что AI постепенно движется от «помоги мне написать код» к «помоги мне довести инженерную задачу до результата». И именно на этом уровне появляется потребность в оркестрации.

Почему одни компании получают от AI больше, чем другие? 🤔

Еще недавно внедрение искусственного интеллекта можно было представить довольно просто: выбрать инструмент, выдать сотрудникам доступ и посмотреть, что произойдет. Но масштабирование AI постепенно меняет эту модель.

По данным PwC, компании и отрасли, наиболее подверженные влиянию AI, демонстрируют более заметный рост производительности. В исследовании PwC 2025 года отмечено, что компании с высокой степенью внедрения AI показали рост выручки на одного сотрудника на 27% против 9% в противоположном случае. В исследовании 2026 года PwC также зафиксировала более высокую производительность у компаний, систематично использующих AI.

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

Для разработки это означает переход от отдельных AI-ассистентов к системам, которые работают с корпоративным контекстом, репозиториями, внутренними инструментами и процессами. И здесь возникают управленческие вопросы:

Если команда использует несколько моделей, кто отвечает за их выбор? Если AI работает с корпоративным кодом, как контролируется доступ? Если агент выполняет десятки действий, как понять, что именно произошло? Если использование AI становится массовым, как измерить его стоимость и эффективность?

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

CodeGryphon изменил код, но как понять, что еще предстоит улучшить? 👨‍💻

CodeGryphon может исправить ошибку, добавить функцию или изменить несколько компонентов проекта. Но из этого вытекают вопросы: что произошло с проектом в целом? Не появились ли ошибки, не сказались ли изменения на производительности, не осталось ли уязвимостей?

Для этого в CodeGryphon есть Пульс проекта. Он показывает состояние проекта по результатам проверок, например: качество кода, безопасность, зависимости и производительность.

Проверку можно создать самостоятельно: наименовать, сообщить, что именно должен проверять CodeGryphon, а затем выбрать периодичность и время запуска. Так контроль проекта можно сделать регулярным, а не вспоминать о нем только после очередного изменения.

Получается автоматизированный процесс:
изменили проект ⤵️
проверили ⤵️
нашли проблему ⤵️
исправили ⤵️
проверили вновь 🔄

Резюмируя, Пульс проекта в CodeGryphon — это инструмент для регулярного контроля состояния проекта после работы агента.