Спасибо за вопрос. В нашем случае речь шла не о greenfield-проекте с нуля, а о продукте, который уже активно развивался и где объём изменений постепенно стал превышать возможности классического код-ревью.
Большая часть задач была вполне типичной для развития продукта: новые фичи, доработка существующей функциональности, исправления, рефакторинг. Именно на таких изменениях мультиагентный подход и дал наибольший эффект - за счёт параллельной проверки разных аспектов кода (логика, стиль, безопасность, потенциальные дефекты и т.д.).
Для небольших проектов или команд из нескольких разработчиков выгода, скорее всего, будет значительно меньше. Наш кейс скорее про продукты, где поток изменений уже достаточно большой, а скорость ревью начинает становиться узким местом.
Спасибо за развёрнутый комментарий. Во многом согласны. Действительно, корпоративная база знаний - это не «папка с документами», а система с разными уровнями информации для разных ролей: архитекторов, разработчиков, тестировщиков, аналитиков, технических писателей и т.д.
В статье мы сознательно не уходили в архитектуру таких систем, а скорее говорили о принципах их формирования и роли корпоративной библиотеки как одного из источников знаний. На практике мы тоже видим, что наиболее рабочая модель сегодня - это сочетание внутренней базы знаний, документации, внешних профессиональных источников и AI-инструментов, которые помогают быстрее находить и связывать информацию, а не заменяют её.
Спасибо за обратную связь. Жаль, что статья оставила такое впечатление. Мы действительно хотели поделиться своим подходом к организации корпоративной базы знаний.
Спасибо за комментарий. Мы, кстати, не противопоставляем корпоративную библиотеку и внутреннюю базу знаний. На практике они решают разные задачи: Wiki отвечает на вопрос «как у нас это устроено?», а книги и внешние материалы - «как эту задачу решают в целом и какие есть подходы». AI действительно становится хорошим слоем поверх обеих систем, помогая быстрее находить нужную информацию.
Заставлять себя читать «через силу» вряд ли имеет смысл. Статья скорее адресована тем, кто сам говорит: «Хочу читать больше, но постоянно не получается». Для людей, которым чтение не близко как формат, могут быть аудио, видео, курсы или другие способы получать знания.
Это скорее две стороны одного процесса. Мотивация отвечает на вопрос «зачем», а привычка - «как сделать так, чтобы это происходило регулярно». Если интереса к теме нет, никакая система не поможет. Но если интерес есть, а времени постоянно не хватает, привычки могут сильно снизить порог входа.
Согласны, что любовь к чтению нельзя "натренировать" так же, как привычку чистить зубы. Скорее, статья про тех, кто хочет читать чаще, но постоянно откладывает. Для них исследования как раз показывают, что небольшие изменения в среде действительно помогают. Если же человеку чтение в принципе неинтересно, универсального рецепта, конечно, нет.
Сама по себе метрика «внутренних переводов» конечно не является прямым ROI библиотеки. Мы смотрели на неё как на proxy-метрику развития и внутренней мобильности сотрудников.
Логика была такая: - если сотрудник проходит ИПР, - пользуется контентом под нужные компетенции, - а потом переходит на новую роль или уровень, то библиотека становится частью системы развития, а не просто «доступом к книгам».
Для бизнеса это важно по двум причинам:
дешевле растить людей внутри, чем искать с рынка;
внутренняя мобильность обычно коррелирует с удержанием сотрудников.
Понятно, что тут нет прямой причинно-следственной связи «прочитал книгу и сразу получил повышение» :) Скорее это один из индикаторов того, что система обучения встроена в реальные HR-процессы, а не существует отдельно от бизнеса.
Если честно, в 2024 многие вещи действительно были скорее «демо ради демо», согласны? ) Очень многое ломалось об качество моделей, скорость, стоимость и отсутствие нормальной интеграции в процессы.
Поэтому у нас и получилось, что часть ранних пилотов просто морально устарела через полгода. Некоторые сценарии, которые тогда требовали отдельной команды и кастомной разработки, сейчас делаются несколькими SaaS-инструментами.
Но, что интересно, организационные проблемы почти не поменялись... мотивация команды, обучение, повторяемость сценариев и интеграция в операционку до сих пор важнее самой модели.
Вообще «AI-пилот» тут скорее в смысле pilot project / PoC, а не «автопилот» - термин действительно уже немного перегрет :)
И мы как раз за два года пришли к тому, что полностью автономный AI в реальной операционке пока сильно переоценён. В большинстве кейсов лучше всего работают всё же не «самостоятельные агенты», а нормальные AI-copilot сценарии для конкретной задачи.
Ну и да, если смотреть только на «количество запусков агентов», это быстро превращается в какой-нибудь vanity metrics. Поэтому мы в итоге смотрим скорее на повторяемость использования и на то, переживает ли сценарий первого энтузиаста в команде 🙂
Спасибо за вопрос. В нашем случае речь шла не о greenfield-проекте с нуля, а о продукте, который уже активно развивался и где объём изменений постепенно стал превышать возможности классического код-ревью.
Большая часть задач была вполне типичной для развития продукта: новые фичи, доработка существующей функциональности, исправления, рефакторинг. Именно на таких изменениях мультиагентный подход и дал наибольший эффект - за счёт параллельной проверки разных аспектов кода (логика, стиль, безопасность, потенциальные дефекты и т.д.).
Для небольших проектов или команд из нескольких разработчиков выгода, скорее всего, будет значительно меньше. Наш кейс скорее про продукты, где поток изменений уже достаточно большой, а скорость ревью начинает становиться узким местом.
Спасибо за развёрнутый комментарий. Во многом согласны. Действительно, корпоративная база знаний - это не «папка с документами», а система с разными уровнями информации для разных ролей: архитекторов, разработчиков, тестировщиков, аналитиков, технических писателей и т.д.
В статье мы сознательно не уходили в архитектуру таких систем, а скорее говорили о принципах их формирования и роли корпоративной библиотеки как одного из источников знаний. На практике мы тоже видим, что наиболее рабочая модель сегодня - это сочетание внутренней базы знаний, документации, внешних профессиональных источников и AI-инструментов, которые помогают быстрее находить и связывать информацию, а не заменяют её.
Спасибо за обратную связь. Жаль, что статья оставила такое впечатление. Мы действительно хотели поделиться своим подходом к организации корпоративной базы знаний.
Спасибо за комментарий. Мы, кстати, не противопоставляем корпоративную библиотеку и внутреннюю базу знаний. На практике они решают разные задачи: Wiki отвечает на вопрос «как у нас это устроено?», а книги и внешние материалы - «как эту задачу решают в целом и какие есть подходы». AI действительно становится хорошим слоем поверх обеих систем, помогая быстрее находить нужную информацию.
Обычно с такими запросами к нам не приходят. Но если нашли решение - не рассказывайте, оно многим не понравится :)
Заставлять себя читать «через силу» вряд ли имеет смысл. Статья скорее адресована тем, кто сам говорит: «Хочу читать больше, но постоянно не получается». Для людей, которым чтение не близко как формат, могут быть аудио, видео, курсы или другие способы получать знания.
Это скорее две стороны одного процесса. Мотивация отвечает на вопрос «зачем», а привычка - «как сделать так, чтобы это происходило регулярно». Если интереса к теме нет, никакая система не поможет. Но если интерес есть, а времени постоянно не хватает, привычки могут сильно снизить порог входа.
Согласны, что любовь к чтению нельзя "натренировать" так же, как привычку чистить зубы. Скорее, статья про тех, кто хочет читать чаще, но постоянно откладывает. Для них исследования как раз показывают, что небольшие изменения в среде действительно помогают. Если же человеку чтение в принципе неинтересно, универсального рецепта, конечно, нет.
Сама по себе метрика «внутренних переводов» конечно не является прямым ROI библиотеки. Мы смотрели на неё как на proxy-метрику развития и внутренней мобильности сотрудников.
Логика была такая:
- если сотрудник проходит ИПР,
- пользуется контентом под нужные компетенции,
- а потом переходит на новую роль или уровень,
то библиотека становится частью системы развития, а не просто «доступом к книгам».
Для бизнеса это важно по двум причинам:
дешевле растить людей внутри, чем искать с рынка;
внутренняя мобильность обычно коррелирует с удержанием сотрудников.
Понятно, что тут нет прямой причинно-следственной связи «прочитал книгу и сразу получил повышение» :) Скорее это один из индикаторов того, что система обучения встроена в реальные HR-процессы, а не существует отдельно от бизнеса.
главный нюанс всей темы 🙂
Если честно, в 2024 многие вещи действительно были скорее «демо ради демо», согласны? ) Очень многое ломалось об качество моделей, скорость, стоимость и отсутствие нормальной интеграции в процессы.
Поэтому у нас и получилось, что часть ранних пилотов просто морально устарела через полгода. Некоторые сценарии, которые тогда требовали отдельной команды и кастомной разработки, сейчас делаются несколькими SaaS-инструментами.
Но, что интересно, организационные проблемы почти не поменялись... мотивация команды, обучение, повторяемость сценариев и интеграция в операционку до сих пор важнее самой модели.
Справедливый комментарий.
Вообще «AI-пилот» тут скорее в смысле pilot project / PoC, а не «автопилот» - термин действительно уже немного перегрет :)
И мы как раз за два года пришли к тому, что полностью автономный AI в реальной операционке пока сильно переоценён. В большинстве кейсов лучше всего работают всё же не «самостоятельные агенты», а нормальные AI-copilot сценарии для конкретной задачи.
Ну и да, если смотреть только на «количество запусков агентов», это быстро превращается в какой-нибудь vanity metrics. Поэтому мы в итоге смотрим скорее на повторяемость использования и на то, переживает ли сценарий первого энтузиаста в команде 🙂