Как перестроить разработку и сократить 250 айтишников
Написал новую статью про один из моих последних кейсов. Название звучит провокационно, но статья не про сокращения ради сокращений.
Она про то, что в старой модели компания может держать 500 инженеров и все равно двигаться медленно: знания находятся в головах людей, документация сильно устарела, требования приходится собирать по чатам, никто в компании не понимает всю архитектуру целиком, а ИИ-инструменты только ускоряют существующий хаос.
В общем, как я в роли CAIO (Chief AI Officer) в международной финтех-компании перестраивал разработку продуктов. Как бы сделать это так, чтобы ничего не сломать?
Главный принцип: AI-Native разработка начинается с правильно оформленной спецификации.
Сначала нужно восстановить текущее состояние системы, понять архитектуру, зависимости и нюансы работы с легаси, потом описать целевое состояние, далее — тесты, и только после этого агентам можно доверять код.
И конечно, строить с нуля намного легче, чем трансформировать что-то существующее.
В статье я разбираю, как устроена AI-Native разработка:
• агент-археолог восстанавливает текущее состояние продукта;
• агент-аналитик превращает спецификацию в центр управления: от фичей и пользовательских историй до описания поведения системы в виде сценариев использования и требований;
• Change Request связывает AS-IS и TO-BE, а агент-менеджер составляет план разработки;
• требования получают ID и мэтчатся с тестами, задачами, релизами и метриками;
• тесты становятся обязательными на всех уровнях архитектуры: так мы переходим к TDD (Test-driven Development);
• организационные изменения, стандартизация спецификаций, дашборды и обучение новым ролям позволяют перейти в новую парадигму.
В итоге за 3 месяца удалось добиться ускорения релиза новых фичей минимум на 20%, в среднем — на 40%, а в некоторых кейсах — от двух до четырех раз.
Сокращения произошли, потому что половина команды не смогла перейти в новую модель. Где-то мешала старая инженерная культура, где-то — открытый или скрытый саботаж. Обучение в формате хакатонов, буткемпов и интенсивов быстро показывает, кто способен учиться, управлять агентами и брать ответственность, а кто продолжает держаться за старое.
Поэтому трансформация — это не только внедрение инструментов, но и обучение текущей команды, выявление ИИ-чемпионов, найм новых людей и постепенная сборка новой культуры разработки. В такой системе меньшая, но более ответственная и адаптивная команда может давать больше результата, чем большая команда, застрявшая в старой парадигме.
В новой AI-Native модели человек управляет продуктом целиком: ставит задачи агентам, управляет контекстом, принимает архитектурные решения, проверяет результат и несет ответственность за весь продукт.
Так появляется новая роль — AI Product Engineer. Поэтому главный вопрос не в сокращениях, а в том, какая команда нужна компании, если больше не надо вручную писать код? Мы же не пишем двоичный код, а пользуемся высокоуровневыми языками программирования – а сегодня используем естественный язык.
Недавно я закончил преподавать курс по AI-Native разработке в университете Пафоса на Кипре, на совместной программе с JetBrains. В рамках курса каждый студент разработал свой стартап, и я был впечатлен качеством работ. После курса один из студентов сказал, что он и до этого писал код с ИИ, но с новым подходом у него «все пошло как по маслу» — появилась уверенность и контроль над системой.
Проблема не только в энтерпрайзе. Большинство людей сегодня учатся разрабатывать продукты с ИИ неправильно: они учатся писать промпты, генерировать куски кода и быстрее выполнять старую работу, либо делают это без спецификаций и тестов, поэтому быстро теряют контроль.
Но будущее не в том, чтобы быстрее делать старую работу, а в том, чтобы строить новую систему. И именно этому теперь надо учить людей — чтобы они быстрее адаптировались к новой реальности.
Ну а я двигаюсь дальше: следующая задача — внедрить AI-Native подход в производство гуманоидных роботов. Следите за обновлениями.
👉 Полная статья
#кейсы
Написал новую статью про один из моих последних кейсов. Название звучит провокационно, но статья не про сокращения ради сокращений.
Она про то, что в старой модели компания может держать 500 инженеров и все равно двигаться медленно: знания находятся в головах людей, документация сильно устарела, требования приходится собирать по чатам, никто в компании не понимает всю архитектуру целиком, а ИИ-инструменты только ускоряют существующий хаос.
В общем, как я в роли CAIO (Chief AI Officer) в международной финтех-компании перестраивал разработку продуктов. Как бы сделать это так, чтобы ничего не сломать?
Главный принцип: AI-Native разработка начинается с правильно оформленной спецификации.
Сначала нужно восстановить текущее состояние системы, понять архитектуру, зависимости и нюансы работы с легаси, потом описать целевое состояние, далее — тесты, и только после этого агентам можно доверять код.
И конечно, строить с нуля намного легче, чем трансформировать что-то существующее.
В статье я разбираю, как устроена AI-Native разработка:
• агент-археолог восстанавливает текущее состояние продукта;
• агент-аналитик превращает спецификацию в центр управления: от фичей и пользовательских историй до описания поведения системы в виде сценариев использования и требований;
• Change Request связывает AS-IS и TO-BE, а агент-менеджер составляет план разработки;
• требования получают ID и мэтчатся с тестами, задачами, релизами и метриками;
• тесты становятся обязательными на всех уровнях архитектуры: так мы переходим к TDD (Test-driven Development);
• организационные изменения, стандартизация спецификаций, дашборды и обучение новым ролям позволяют перейти в новую парадигму.
В итоге за 3 месяца удалось добиться ускорения релиза новых фичей минимум на 20%, в среднем — на 40%, а в некоторых кейсах — от двух до четырех раз.
Сокращения произошли, потому что половина команды не смогла перейти в новую модель. Где-то мешала старая инженерная культура, где-то — открытый или скрытый саботаж. Обучение в формате хакатонов, буткемпов и интенсивов быстро показывает, кто способен учиться, управлять агентами и брать ответственность, а кто продолжает держаться за старое.
Поэтому трансформация — это не только внедрение инструментов, но и обучение текущей команды, выявление ИИ-чемпионов, найм новых людей и постепенная сборка новой культуры разработки. В такой системе меньшая, но более ответственная и адаптивная команда может давать больше результата, чем большая команда, застрявшая в старой парадигме.
В новой AI-Native модели человек управляет продуктом целиком: ставит задачи агентам, управляет контекстом, принимает архитектурные решения, проверяет результат и несет ответственность за весь продукт.
Так появляется новая роль — AI Product Engineer. Поэтому главный вопрос не в сокращениях, а в том, какая команда нужна компании, если больше не надо вручную писать код? Мы же не пишем двоичный код, а пользуемся высокоуровневыми языками программирования – а сегодня используем естественный язык.
Недавно я закончил преподавать курс по AI-Native разработке в университете Пафоса на Кипре, на совместной программе с JetBrains. В рамках курса каждый студент разработал свой стартап, и я был впечатлен качеством работ. После курса один из студентов сказал, что он и до этого писал код с ИИ, но с новым подходом у него «все пошло как по маслу» — появилась уверенность и контроль над системой.
Проблема не только в энтерпрайзе. Большинство людей сегодня учатся разрабатывать продукты с ИИ неправильно: они учатся писать промпты, генерировать куски кода и быстрее выполнять старую работу, либо делают это без спецификаций и тестов, поэтому быстро теряют контроль.
Но будущее не в том, чтобы быстрее делать старую работу, а в том, чтобы строить новую систему. И именно этому теперь надо учить людей — чтобы они быстрее адаптировались к новой реальности.
Ну а я двигаюсь дальше: следующая задача — внедрить AI-Native подход в производство гуманоидных роботов. Следите за обновлениями.
👉 Полная статья
#кейсы
Датаист / Кейсы
Как перестроить разработку в AI-Native режим
Реальный кейс ИИ-трансформации разработки: от легаси и хаоса к AI-Native подходу, спецификациям и сокращению рутины.
3👍23🔥14
Закрытие Fable 5 — новый прецедент для ИИ-индустрии
США фактически впервые публично применили к ИИ-модели логику экспортного контроля не только как к чипам и дата-центрам, но как к интеллектуальному продукту.
Anthropic получила директиву приостановить доступ к Fable 5 и Mythos 5 для иностранных граждан, включая иностранных сотрудников самой Anthropic. В результате спустя три дня после релиза компания была вынуждена отключить модели для всех клиентов.
Anthropic называла Fable 5 безопасной версией Mythos 5, а Mythos 5 оставалась недоступной для широкой аудитории: ее планировали открыть для исследований.
Anthropic утверждает, что перед запуском провела тысячи часов тестирования вместе с правительством США. По словам компании, система безопасности Fable оказалась эффективнее, чем у ранее развернутых моделей.
На самом деле это важное событие. Доступ к передовому интеллекту теперь может зависеть от органов национальной безопасности.
Anthropic утверждает, что правительство не дало конкретных деталей угрозы, а описанные в демонстрации уязвимости присутствуют и в других публичных моделях.
Для некоторых тем в кибербезопасности, биологии и химии Fable 5 могла отдавать ответ через Claude Opus 4.8, чтобы снизить риск выдачи вредного ответа.
Но Anthropic утверждает, что такой fallback срабатывал менее чем в 5% сессий, а идеального механизма безопасности сегодня не существует.
Я сам несколько дней пользовался Fable 5 в рабочих задачах. Модель действительно лучше держала длинный контекст, особенно на больших кодовых базах.
Она была более автономной: чаще сама писала скрипты для миграций, рефакторинга и операций с файлами, в общем работала как полноценный инженер.
Конечно, после отключения Fable 5 возвращаться к предыдущему поколению моделей уже сложно.
Именно это и показывает реальный риск нового поколения моделей. Чем модель полезнее, тем она агентнее. Чем она агентнее, тем больше она похожа на цифрового сотрудника. Чем больше она похожа на сотрудника, тем сильнее вопрос контроля.
Илья Суцкевер говорил об этом: чем больше модель рассуждает и действует самостоятельно, тем менее предсказуемым становится ее поведение.
Fable 5 могла быть слишком инициативной и быстрее съедала лимиты токенов. То есть этот более умный инструмент требует новой архитектуры управления.
Anthropic не спорит с тем, что государство должно иметь право блокировать действительно опасные модели, но компания считает, что это должно происходить через прозрачный процесс. В этой ситуации, по словам Anthropic, такого процесса не было.
Anthropic прямо пишет: если такой стандарт применить ко всей индустрии, это фактически остановит все новые деплои передовых моделей.
Ранее администрация США конфликтовала с Anthropic из-за ограничений на военное применение моделей, а сама компания, по сообщениям СМИ, была помещена в черный список контрагентов.
Главный вывод для бизнеса такой: сегодня ставка на одного ИИ-провайдера становится стратегическим риском.
Если ваша компания построена на одной модели, то ее могут отменить за то, что она слишком умная.
Поэтому стройте решения без жесткой привязки к провайдеру. Нужен слой маршрутизации между моделями и возможность переключать задачи между OpenAI, Anthropic, Google и локальными моделями.
Fable 5 могут включить обратно. Конкретный конфликт Anthropic и правительства может разрешиться, но прецедент уже создан.
ИИ-модели теперь окончательно стали инструментом геополитики.
А значит, выиграют те, кто сумел построить автономную интеллектуальную систему, способную пережить отключение любой модели, сервиса и даже интернета.
#новости
США фактически впервые публично применили к ИИ-модели логику экспортного контроля не только как к чипам и дата-центрам, но как к интеллектуальному продукту.
Anthropic получила директиву приостановить доступ к Fable 5 и Mythos 5 для иностранных граждан, включая иностранных сотрудников самой Anthropic. В результате спустя три дня после релиза компания была вынуждена отключить модели для всех клиентов.
Anthropic называла Fable 5 безопасной версией Mythos 5, а Mythos 5 оставалась недоступной для широкой аудитории: ее планировали открыть для исследований.
Anthropic утверждает, что перед запуском провела тысячи часов тестирования вместе с правительством США. По словам компании, система безопасности Fable оказалась эффективнее, чем у ранее развернутых моделей.
На самом деле это важное событие. Доступ к передовому интеллекту теперь может зависеть от органов национальной безопасности.
Anthropic утверждает, что правительство не дало конкретных деталей угрозы, а описанные в демонстрации уязвимости присутствуют и в других публичных моделях.
Для некоторых тем в кибербезопасности, биологии и химии Fable 5 могла отдавать ответ через Claude Opus 4.8, чтобы снизить риск выдачи вредного ответа.
Но Anthropic утверждает, что такой fallback срабатывал менее чем в 5% сессий, а идеального механизма безопасности сегодня не существует.
Я сам несколько дней пользовался Fable 5 в рабочих задачах. Модель действительно лучше держала длинный контекст, особенно на больших кодовых базах.
Она была более автономной: чаще сама писала скрипты для миграций, рефакторинга и операций с файлами, в общем работала как полноценный инженер.
Конечно, после отключения Fable 5 возвращаться к предыдущему поколению моделей уже сложно.
Именно это и показывает реальный риск нового поколения моделей. Чем модель полезнее, тем она агентнее. Чем она агентнее, тем больше она похожа на цифрового сотрудника. Чем больше она похожа на сотрудника, тем сильнее вопрос контроля.
Илья Суцкевер говорил об этом: чем больше модель рассуждает и действует самостоятельно, тем менее предсказуемым становится ее поведение.
Fable 5 могла быть слишком инициативной и быстрее съедала лимиты токенов. То есть этот более умный инструмент требует новой архитектуры управления.
Anthropic не спорит с тем, что государство должно иметь право блокировать действительно опасные модели, но компания считает, что это должно происходить через прозрачный процесс. В этой ситуации, по словам Anthropic, такого процесса не было.
Anthropic прямо пишет: если такой стандарт применить ко всей индустрии, это фактически остановит все новые деплои передовых моделей.
Ранее администрация США конфликтовала с Anthropic из-за ограничений на военное применение моделей, а сама компания, по сообщениям СМИ, была помещена в черный список контрагентов.
Главный вывод для бизнеса такой: сегодня ставка на одного ИИ-провайдера становится стратегическим риском.
Если ваша компания построена на одной модели, то ее могут отменить за то, что она слишком умная.
Поэтому стройте решения без жесткой привязки к провайдеру. Нужен слой маршрутизации между моделями и возможность переключать задачи между OpenAI, Anthropic, Google и локальными моделями.
Fable 5 могут включить обратно. Конкретный конфликт Anthropic и правительства может разрешиться, но прецедент уже создан.
ИИ-модели теперь окончательно стали инструментом геополитики.
А значит, выиграют те, кто сумел построить автономную интеллектуальную систему, способную пережить отключение любой модели, сервиса и даже интернета.
#новости
Anthropic
Statement on the US government directive to suspend access to Fable 5 and Mythos 5
The US government has issued an export control directive to suspend all access to Fable 5 and Mythos 5 by any foreign national, whether inside or outside the United States.
2👍21❤4👏2🤯2⚡1💯1🦄1
10 причин провала ИИ-трансформации — и почему ИИ-компанию бывает проще запустить с нуля
Написал новую статью, но не потому, что разочаровался в ИИ-трансформациях.
Скорее наоборот – слишком долго этим занимался.
Первый опыт был еще в Accenture, а потом в Сбере около десяти лет назад.
Тогда мы строили хранилища данных, чтобы использовать их для обучения моделей и продвинутой аналитики для принятия решений. Потом были и другие крупные трансформации.
И за это время я стал чаще замечать одну вещь.
Большую компанию можно трансформировать, но цена этой трансформации порой оказывается сильно выше, чем кажется в начале.
Проблема не только в данных, легаси, безопасности или качестве моделей. Это все важные, но технически решаемые задачи.
Главная сложность в том, что ИИ вскрывает само устройство компании, а ИИ-трансформация становится проверкой зрелости организации.
И если для внедрения ИИ в большую компанию сначала нужно сделать ее прозрачной и управляемой, то возникает вопрос: где заканчивается трансформация и начинается создание новой компании?
В какой момент дешевле не перестраивать старую систему, а собрать новую сразу под ИИ?
И отсюда появляется следующий вопрос: если сегодня один человек с агентами уже может делать то, для чего раньше требовалась целая команда, то какую компанию вообще имеет смысл строить?
Мне кажется, сейчас наступает время тех, кто начинает с нуля: соло-предпринимателей, небольших команд и сильных специалистов, которые не хотят тратить годы на обслуживание чужого легаси.
Они быстрее проверяют гипотезы, не тратя месяцы на согласование того, как именно их проверять.
Но важнее даже не это.
Меняется сама роль человека в новой экономике.
Сотрудник как юнит внутри структуры постепенно перестает быть единственной нормой.
Человек может сам становиться экономическим узлом: предоставлять сервис или создавать продукт.
Один узел создает ценность, еще один ее переиспользует и собирает из нескольких сервисов новый продукт. Другой запускает AI-First бизнес как оператор и помогает фаундерам строить AI-Native компанию.
Так новая экономика начинает собираться не из должностей, а из продуктов и сервисов, за которыми стоят реальные люди.
Поэтому ИИ-суперсила, которая раньше была преимуществом корпораций, должна стать доступна тем, кто строит с нуля.
В статье разбираю 10 причин, почему ИИ-трансформация проваливается даже в передовых компаниях.
Когда стоит перестраивать старую систему, а когда пора собрать новую под новые экономические реалии?
👉 Полная статья
#мысли
Написал новую статью, но не потому, что разочаровался в ИИ-трансформациях.
Скорее наоборот – слишком долго этим занимался.
Первый опыт был еще в Accenture, а потом в Сбере около десяти лет назад.
Тогда мы строили хранилища данных, чтобы использовать их для обучения моделей и продвинутой аналитики для принятия решений. Потом были и другие крупные трансформации.
И за это время я стал чаще замечать одну вещь.
Большую компанию можно трансформировать, но цена этой трансформации порой оказывается сильно выше, чем кажется в начале.
Проблема не только в данных, легаси, безопасности или качестве моделей. Это все важные, но технически решаемые задачи.
Главная сложность в том, что ИИ вскрывает само устройство компании, а ИИ-трансформация становится проверкой зрелости организации.
И если для внедрения ИИ в большую компанию сначала нужно сделать ее прозрачной и управляемой, то возникает вопрос: где заканчивается трансформация и начинается создание новой компании?
В какой момент дешевле не перестраивать старую систему, а собрать новую сразу под ИИ?
И отсюда появляется следующий вопрос: если сегодня один человек с агентами уже может делать то, для чего раньше требовалась целая команда, то какую компанию вообще имеет смысл строить?
Мне кажется, сейчас наступает время тех, кто начинает с нуля: соло-предпринимателей, небольших команд и сильных специалистов, которые не хотят тратить годы на обслуживание чужого легаси.
Они быстрее проверяют гипотезы, не тратя месяцы на согласование того, как именно их проверять.
Но важнее даже не это.
Меняется сама роль человека в новой экономике.
Сотрудник как юнит внутри структуры постепенно перестает быть единственной нормой.
Человек может сам становиться экономическим узлом: предоставлять сервис или создавать продукт.
Один узел создает ценность, еще один ее переиспользует и собирает из нескольких сервисов новый продукт. Другой запускает AI-First бизнес как оператор и помогает фаундерам строить AI-Native компанию.
Так новая экономика начинает собираться не из должностей, а из продуктов и сервисов, за которыми стоят реальные люди.
Поэтому ИИ-суперсила, которая раньше была преимуществом корпораций, должна стать доступна тем, кто строит с нуля.
В статье разбираю 10 причин, почему ИИ-трансформация проваливается даже в передовых компаниях.
Когда стоит перестраивать старую систему, а когда пора собрать новую под новые экономические реалии?
👉 Полная статья
#мысли
Датаист / Мысли
10 причин провала ИИ-трансформации — и почему ИИ-компанию бывает проще запустить с нуля
После десятка лет работы с ИИ-трансформациями у меня появился неприличный вопрос для компаний: что проще — изменить большую компанию или построить новую с нуля?
3👍20🔥10❤7👏1
Loop Engineering: новый хайп или конец ручного промтинга?
Сначала все учились писать хорошие промты, и ненадолго даже появилась целая профессия промт-инженера. Казалось, что главный навык будущего — это умение просить модель исполнять нужную роль, описывать формат ответа, добавлять примеры и ограничения, чтобы получать ожидаемый результат.
Потом стало понятно, что одного промта мало. Модель не может качественно решать задачу, если она не понимает контекст: какие есть документы и как устроен проект. Так появилась инженерия контекста: умение предоставить модели такую информацию, чтобы она могла выдавать более осмысленные ответы.
Следующий уровень — обвязка вокруг модели в виде инструментов, песочницы, логов, памяти и прав на совершение действий. Потому что модель без среды просто отвечает текстом, а агент в правильно организованной среде уже может действовать.
Но сейчас инженеры “придумали” следующий уровень — инженерию циклов, или Loop Engineering.
Это когда человек больше не пишет каждый следующий запрос агенту вручную. Вместо этого он проектирует систему, которая сама запускает агента в нужный момент, дает ему правильный контекст, выполняет действие, получает обратную связь от среды, проверяет результат и решает, нужно ли продолжать или все цели достигнуты.
Человек больше не контролирует каждый шаг агента. Он становится архитектором процесса, в котором агент может работать, не теряя заданную цель, контекст, прогресс и критерии качества.
Главное здесь — не автономность сама по себе, а проверяемость.
Хороший цикл — это система, у которой есть условие запуска и завершения, тело цикла, среда выполнения и ограничения.
Такие циклы особенно полезны там, где есть повторяющаяся работа и понятная проверка результата.
Простой пример, о котором я писал ранее, — разработка через тесты (Test-Driven Development). Мы заранее описываем, что должно работать, а агент пишет код, запускает проверки, получает ошибки, исправляет, снова проверяет и не завершает задачу, пока система не увидит доказательство, что результат достигнут.
Но даже здесь есть ловушка: успешные проверки еще не означают, что продукт работает. Самый опасный сценарий — когда формально все тесты зеленые, но реальный пользовательский путь сломан.
Проектировать хорошие циклы нужно уметь. Иначе агент будет тратить ресурсы, ошибаться и в конце принесет результат, которому нельзя доверять.
Новые циклы лучше сразу не делать автономными. Сначала их нужно запустить вручную, посмотреть первый полный проход, убедиться, что они правильно сохраняют состояние, не тащат лишний контекст, не делают опасных действий и действительно работают так, как было задумано. Только после этого их можно ставить на расписание или запуск по событию.
Циклы нужно превращать в переиспользуемые навыки. Так у вас появится библиотека рабочих процессов, которые можно встраивать в более сложные системы.
Самоулучшающийся цикл — это когда система записала обобщенное правило в файл, который будет прочитан при следующем запуске. Это может быть полезно, если правило действительно улучшает будущую работу. Но если цикл пишет себе правила без внешней проверки, то агент может “выучить” неверный урок. Поэтому самоулучшение без проверяющего — это новый риск.
Отдельная проблема — контекст. Цикл пересылает контекст на каждом проходе, поэтому лишняя информация быстро раздувает бюджет на токены и плодит ошибки.
Циклы — это недостающее звено системы, в которой агенты могут действовать самостоятельно. Однако ИИ-агент может быть автономным ровно настолько, насколько система умеет проверять его работу.
Поэтому новый важный навык — умение строить циклы, которым можно доверять.
#технологии
Сначала все учились писать хорошие промты, и ненадолго даже появилась целая профессия промт-инженера. Казалось, что главный навык будущего — это умение просить модель исполнять нужную роль, описывать формат ответа, добавлять примеры и ограничения, чтобы получать ожидаемый результат.
Потом стало понятно, что одного промта мало. Модель не может качественно решать задачу, если она не понимает контекст: какие есть документы и как устроен проект. Так появилась инженерия контекста: умение предоставить модели такую информацию, чтобы она могла выдавать более осмысленные ответы.
Следующий уровень — обвязка вокруг модели в виде инструментов, песочницы, логов, памяти и прав на совершение действий. Потому что модель без среды просто отвечает текстом, а агент в правильно организованной среде уже может действовать.
Но сейчас инженеры “придумали” следующий уровень — инженерию циклов, или Loop Engineering.
Это когда человек больше не пишет каждый следующий запрос агенту вручную. Вместо этого он проектирует систему, которая сама запускает агента в нужный момент, дает ему правильный контекст, выполняет действие, получает обратную связь от среды, проверяет результат и решает, нужно ли продолжать или все цели достигнуты.
Человек больше не контролирует каждый шаг агента. Он становится архитектором процесса, в котором агент может работать, не теряя заданную цель, контекст, прогресс и критерии качества.
Главное здесь — не автономность сама по себе, а проверяемость.
Хороший цикл — это система, у которой есть условие запуска и завершения, тело цикла, среда выполнения и ограничения.
Такие циклы особенно полезны там, где есть повторяющаяся работа и понятная проверка результата.
Простой пример, о котором я писал ранее, — разработка через тесты (Test-Driven Development). Мы заранее описываем, что должно работать, а агент пишет код, запускает проверки, получает ошибки, исправляет, снова проверяет и не завершает задачу, пока система не увидит доказательство, что результат достигнут.
Но даже здесь есть ловушка: успешные проверки еще не означают, что продукт работает. Самый опасный сценарий — когда формально все тесты зеленые, но реальный пользовательский путь сломан.
Проектировать хорошие циклы нужно уметь. Иначе агент будет тратить ресурсы, ошибаться и в конце принесет результат, которому нельзя доверять.
Новые циклы лучше сразу не делать автономными. Сначала их нужно запустить вручную, посмотреть первый полный проход, убедиться, что они правильно сохраняют состояние, не тащат лишний контекст, не делают опасных действий и действительно работают так, как было задумано. Только после этого их можно ставить на расписание или запуск по событию.
Циклы нужно превращать в переиспользуемые навыки. Так у вас появится библиотека рабочих процессов, которые можно встраивать в более сложные системы.
Самоулучшающийся цикл — это когда система записала обобщенное правило в файл, который будет прочитан при следующем запуске. Это может быть полезно, если правило действительно улучшает будущую работу. Но если цикл пишет себе правила без внешней проверки, то агент может “выучить” неверный урок. Поэтому самоулучшение без проверяющего — это новый риск.
Отдельная проблема — контекст. Цикл пересылает контекст на каждом проходе, поэтому лишняя информация быстро раздувает бюджет на токены и плодит ошибки.
Циклы — это недостающее звено системы, в которой агенты могут действовать самостоятельно. Однако ИИ-агент может быть автономным ровно настолько, насколько система умеет проверять его работу.
Поэтому новый важный навык — умение строить циклы, которым можно доверять.
#технологии
4❤13👍8🔥7👏1🙏1
Инвестиции не нужны: как ИИ меняет венчур. Часть 1
В 2019 году я выиграл акселератор Сбера с дейтинг-сервисом на базе ИИ с несколькими тысячами пользователей.
Мне предложили 2 млн рублей за 10% компании, а в дальнейшем Сбер мог увеличить долю до 50% по той же цене акций и получить контроль.
Я отказался. Этих денег хватило бы на месяц работы, а в топ-менеджменте Сбера я мог спокойно заработать эту сумму за квартал.
Получается, что ради месяца расходов я должен был навсегда отдать часть компании и потерять свободу.
Согласно опросу, 87% наших пользователей ушли бы из сервиса, если бы мы «продались» Сберу.
Кроме того, условия акселератора лишали меня возможности независимо развивать стартап в течение трех лет.
Тогда в дейтинге многие пользователи успели найти своего человека, поэтому вскоре я его похоронил.
В то время инвестиции казались обязательными, но сегодня все изменилось.
Еще пару лет назад для разработки продукта требовалась команда примерно из десяти человек: пара бэкендеров и фронтендеров, аналитик, дизайнер, ИИ-инженер, QA, маркетолог и тимлид, дирижировавший этим оркестром.
Когда я работал CTO в венчурной студии, одними из основных метрик были количество и скорость проверки гипотез.
Мы закладывали около миллиона долларов в год на одну продуктовую команду — с учетом зарплат, налогов и инфраструктуры.
Основатель продавал долю еще до того, как понимал, какой продукт действительно нужен рынку, а инвестор на ранних стадиях фактически финансировал время команды для проверки гипотез.
ИИ перевернул эту модель с ног на голову.
Теперь основатели не бегают за инвесторами, а сами инвесторы пытаются понять, в каких людей и на каких условиях стоит инвестировать.
Да, для чипов, биотехнологий, робототехники и фундаментальных моделей это не работает. Но для SaaS, ИИ-агентов, автоматизаций и AI-First бизнесов такая экономика уже реальна.
Сегодня очевидно, что с помощью ИИ можно самостоятельно исследовать рынок, разработать продукт вместе с агентами — не завайбкодить, а именно выстроить полноценный инженерный процесс — и провести первые продажи.
Возможно, один человек не сможет в одиночку вытянуть миллиардную компанию (но это неточно). Но он точно способен потянуть раннюю стадию.
Следовательно, порог входа в технологическое предпринимательство радикально снизился.
Если год работы команды стоит около миллиона долларов, то одному основателю нужно порядка $100к. Так потребность в раннем капитале сокращается в десять раз.
Главным расходом становится время и фокус человека, который умеет строить.
Если крутой специалист зарабатывает $10к в месяц, тратит $5к на жизнь и откладывает остальные $5к, то $100к он накопит за пару лет. Конечно, все зависит от локации и уровня расходов.
Через свою компанию это можно сделать быстрее: консалтинг, разработка и внедрение ИИ создают кэшфлоу, который затем финансирует собственные продукты. Я сам прошел этот путь.
Я уехал строить бизнес на Кипр четыре года назад с нулем в кармане, оставив все, что у меня было, кроме своих знаний и опыта.
Конечно, сразу выйти на хороший доход в новой среде было непросто. Тем более что мне, как россиянину, больше года открывали компанию и корпоративный счет.
Это было крайне тяжелое время: я технически не мог принимать оплаты и поэтому выживал как мог. Если интересно, об этом пути могу написать отдельную статью.
Но постепенно прибыль более $300к в год без единого сотрудника стала реальностью.
Правда, у регулятора до сих пор есть вопросы к регистрации моих разработок: мол, в штате компании должны быть сотрудники. Когда я объясняю, что весь код написан ИИ, это вызывает недоумение и создает прецедент.
Ох уж этот архаичный старый мир… Но это уже другая история.
Так главным конкурентом венчурного фонда становится способность основателя самостоятельно обеспечить себе финансовую свободу.
«Инвестиции не нужны» не означает, что капитал больше вообще не нужен. Это значит, что инвестиции перестают быть обязательным условием для создания своей ИИ-компании.
Во второй части расскажу, какая модель может прийти на смену классическому венчуру.
#мысли
В 2019 году я выиграл акселератор Сбера с дейтинг-сервисом на базе ИИ с несколькими тысячами пользователей.
Мне предложили 2 млн рублей за 10% компании, а в дальнейшем Сбер мог увеличить долю до 50% по той же цене акций и получить контроль.
Я отказался. Этих денег хватило бы на месяц работы, а в топ-менеджменте Сбера я мог спокойно заработать эту сумму за квартал.
Получается, что ради месяца расходов я должен был навсегда отдать часть компании и потерять свободу.
Согласно опросу, 87% наших пользователей ушли бы из сервиса, если бы мы «продались» Сберу.
Кроме того, условия акселератора лишали меня возможности независимо развивать стартап в течение трех лет.
Тогда в дейтинге многие пользователи успели найти своего человека, поэтому вскоре я его похоронил.
В то время инвестиции казались обязательными, но сегодня все изменилось.
Еще пару лет назад для разработки продукта требовалась команда примерно из десяти человек: пара бэкендеров и фронтендеров, аналитик, дизайнер, ИИ-инженер, QA, маркетолог и тимлид, дирижировавший этим оркестром.
Когда я работал CTO в венчурной студии, одними из основных метрик были количество и скорость проверки гипотез.
Мы закладывали около миллиона долларов в год на одну продуктовую команду — с учетом зарплат, налогов и инфраструктуры.
Основатель продавал долю еще до того, как понимал, какой продукт действительно нужен рынку, а инвестор на ранних стадиях фактически финансировал время команды для проверки гипотез.
ИИ перевернул эту модель с ног на голову.
Теперь основатели не бегают за инвесторами, а сами инвесторы пытаются понять, в каких людей и на каких условиях стоит инвестировать.
Да, для чипов, биотехнологий, робототехники и фундаментальных моделей это не работает. Но для SaaS, ИИ-агентов, автоматизаций и AI-First бизнесов такая экономика уже реальна.
Сегодня очевидно, что с помощью ИИ можно самостоятельно исследовать рынок, разработать продукт вместе с агентами — не завайбкодить, а именно выстроить полноценный инженерный процесс — и провести первые продажи.
Возможно, один человек не сможет в одиночку вытянуть миллиардную компанию (но это неточно). Но он точно способен потянуть раннюю стадию.
Следовательно, порог входа в технологическое предпринимательство радикально снизился.
Если год работы команды стоит около миллиона долларов, то одному основателю нужно порядка $100к. Так потребность в раннем капитале сокращается в десять раз.
Главным расходом становится время и фокус человека, который умеет строить.
Если крутой специалист зарабатывает $10к в месяц, тратит $5к на жизнь и откладывает остальные $5к, то $100к он накопит за пару лет. Конечно, все зависит от локации и уровня расходов.
Через свою компанию это можно сделать быстрее: консалтинг, разработка и внедрение ИИ создают кэшфлоу, который затем финансирует собственные продукты. Я сам прошел этот путь.
Я уехал строить бизнес на Кипр четыре года назад с нулем в кармане, оставив все, что у меня было, кроме своих знаний и опыта.
Конечно, сразу выйти на хороший доход в новой среде было непросто. Тем более что мне, как россиянину, больше года открывали компанию и корпоративный счет.
Это было крайне тяжелое время: я технически не мог принимать оплаты и поэтому выживал как мог. Если интересно, об этом пути могу написать отдельную статью.
Но постепенно прибыль более $300к в год без единого сотрудника стала реальностью.
Правда, у регулятора до сих пор есть вопросы к регистрации моих разработок: мол, в штате компании должны быть сотрудники. Когда я объясняю, что весь код написан ИИ, это вызывает недоумение и создает прецедент.
Ох уж этот архаичный старый мир… Но это уже другая история.
Так главным конкурентом венчурного фонда становится способность основателя самостоятельно обеспечить себе финансовую свободу.
«Инвестиции не нужны» не означает, что капитал больше вообще не нужен. Это значит, что инвестиции перестают быть обязательным условием для создания своей ИИ-компании.
Во второй части расскажу, какая модель может прийти на смену классическому венчуру.
#мысли
2🔥19❤9👍5🙏1
Инвестиции не нужны: как ИИ меняет венчур. Часть 2
В первой части я рассказал, почему инвестиции перестают быть обязательным входным билетом в технологическое предпринимательство.
На мой взгляд, на смену классическому венчуру может прийти гибридная модель.
Вчера венчур был устроен просто: инвестор переводит деньги, а основатель отдает долю. Но бизнесу нужен не только капитал. Ему нужны время и фокус основателя, доверие клиентов и доступ к рынку.
У инженера, способного самостоятельно создать продукт, обычно три вопроса: что строить, на что жить во время разработки и как затем выйти к клиентам.
Первый вопрос решает система, которая помогает определить реальную потребность рынка. О ней расскажу в конце.
Второй можно закрыть так, как сделал я: сначала заработать капитал, а затем финансировать свои продукты.
Либо через краудфандинг. Будущие пользователи заранее финансируют разработку, а взамен получают пожизненный доступ, специальные условия, возможность влиять на развитие продукта или другие плюшки.
Так вместо одного инвестора с крупным чеком появляются десятки или сотни первых последователей, заинтересованных в успехе продукта.
Они одновременно дают основателю время на разработку, подтверждают спрос и становятся первыми клиентами.
Третий вопрос решается партнерством.
Тот, кто предоставляет доступ к клиентам и рынку, получает revenue share. Не долю во всей компании, а вознаграждение за конкретный результат.
В итоге основатель получает возможность спокойно строить, пользователи финансируют нужный им продукт, а партнеры зарабатывают на открытых ими рынках.
Гибридность заключается в том, что один «инвестор» может одновременно дать деньги, стать первым клиентом и открыть новый рынок.
Тут важно быть особенно внимательным с условиями партнерства, чтобы помощь с выходом на рынок не превратилась в рейдерский захват.
Например, недавно один инвестор предложил мне инвестиции, от которых я отказался.
Тогда он предложил стать партнером и продвигать мой продукт, но попытался хитро заложить в договор фактический контроль над моей интеллектуальной собственностью — по его выражению, чтобы «оседлать этого коня». Благо юристы вовремя это обнаружили.
ИИ меняет и сам подход к формированию команды. Теперь больше гипотез можно проверять силами нескольких талантливых людей, готовых брать на себя ответственность за результат и приобретать бесценный опыт.
У меня самого была подобная стратегия: поработать лет 10 с опытными CEO, чтобы учиться на их опыте и совершать меньше собственных ошибок.
Раньше в Сбере мне «поставляли» десятки стажеров. Сегодня мне по-прежнему предлагают такую опцию, но я выбираю только невероятно талантливых. Количество людей в команде не коррелирует с качеством продукта.
Вчера мой стажер выиграл грант в миллион рублей на продолжение моего дела – дейтинг-сервиса. Я готов вкладываться в новое поколение предпринимателей и передавать свой опыт.
Если вы хотите научиться строить ИИ-продукты, ребята из AI Talent Hub, которым я помогаю, сейчас открывают набор в магистратуру ИТМО.
С осени я продолжу там же вести свой курс по ИИ-агентам, а на следующей неделе анонсирую бесплатный курс для всех — чтобы больше людей могли воплощать свои идеи в жизнь и строить ИИ-компании.
Путь предпринимателя тернист. Гораздо проще «крутить гайку» в бигтехе, но в то же время это путь к свободе, которую я ценю больше всего.
Товарищи технари, если вы умеете самостоятельно создавать продукты, сегодня ваше время.
Разобраться в рынке, продажах и экономике продукта, на мой взгляд, легче, чем разобраться в инженерном деле — даже с ИИ.
Мы, инженеры, знаем, как строить, но не всегда знаем, что именно. Однако мы можем создать систему, которая подскажет, что действительно нужно людям.
Поэтому я подготовил для вас статью о том, как собрать себе такую систему.
Как бы сказал Брюс Ли в наши дни:
Так вместе мы сможем построить новую экономику, в которой ИИ усиливает свободных людей.
#мысли
В первой части я рассказал, почему инвестиции перестают быть обязательным входным билетом в технологическое предпринимательство.
На мой взгляд, на смену классическому венчуру может прийти гибридная модель.
Вчера венчур был устроен просто: инвестор переводит деньги, а основатель отдает долю. Но бизнесу нужен не только капитал. Ему нужны время и фокус основателя, доверие клиентов и доступ к рынку.
У инженера, способного самостоятельно создать продукт, обычно три вопроса: что строить, на что жить во время разработки и как затем выйти к клиентам.
Первый вопрос решает система, которая помогает определить реальную потребность рынка. О ней расскажу в конце.
Второй можно закрыть так, как сделал я: сначала заработать капитал, а затем финансировать свои продукты.
Либо через краудфандинг. Будущие пользователи заранее финансируют разработку, а взамен получают пожизненный доступ, специальные условия, возможность влиять на развитие продукта или другие плюшки.
Так вместо одного инвестора с крупным чеком появляются десятки или сотни первых последователей, заинтересованных в успехе продукта.
Они одновременно дают основателю время на разработку, подтверждают спрос и становятся первыми клиентами.
Третий вопрос решается партнерством.
Тот, кто предоставляет доступ к клиентам и рынку, получает revenue share. Не долю во всей компании, а вознаграждение за конкретный результат.
В итоге основатель получает возможность спокойно строить, пользователи финансируют нужный им продукт, а партнеры зарабатывают на открытых ими рынках.
Гибридность заключается в том, что один «инвестор» может одновременно дать деньги, стать первым клиентом и открыть новый рынок.
Тут важно быть особенно внимательным с условиями партнерства, чтобы помощь с выходом на рынок не превратилась в рейдерский захват.
Например, недавно один инвестор предложил мне инвестиции, от которых я отказался.
Тогда он предложил стать партнером и продвигать мой продукт, но попытался хитро заложить в договор фактический контроль над моей интеллектуальной собственностью — по его выражению, чтобы «оседлать этого коня». Благо юристы вовремя это обнаружили.
ИИ меняет и сам подход к формированию команды. Теперь больше гипотез можно проверять силами нескольких талантливых людей, готовых брать на себя ответственность за результат и приобретать бесценный опыт.
У меня самого была подобная стратегия: поработать лет 10 с опытными CEO, чтобы учиться на их опыте и совершать меньше собственных ошибок.
Раньше в Сбере мне «поставляли» десятки стажеров. Сегодня мне по-прежнему предлагают такую опцию, но я выбираю только невероятно талантливых. Количество людей в команде не коррелирует с качеством продукта.
Вчера мой стажер выиграл грант в миллион рублей на продолжение моего дела – дейтинг-сервиса. Я готов вкладываться в новое поколение предпринимателей и передавать свой опыт.
Если вы хотите научиться строить ИИ-продукты, ребята из AI Talent Hub, которым я помогаю, сейчас открывают набор в магистратуру ИТМО.
С осени я продолжу там же вести свой курс по ИИ-агентам, а на следующей неделе анонсирую бесплатный курс для всех — чтобы больше людей могли воплощать свои идеи в жизнь и строить ИИ-компании.
Путь предпринимателя тернист. Гораздо проще «крутить гайку» в бигтехе, но в то же время это путь к свободе, которую я ценю больше всего.
Товарищи технари, если вы умеете самостоятельно создавать продукты, сегодня ваше время.
Разобраться в рынке, продажах и экономике продукта, на мой взгляд, легче, чем разобраться в инженерном деле — даже с ИИ.
Мы, инженеры, знаем, как строить, но не всегда знаем, что именно. Однако мы можем создать систему, которая подскажет, что действительно нужно людям.
Поэтому я подготовил для вас статью о том, как собрать себе такую систему.
Как бы сказал Брюс Ли в наши дни:
«Я не боюсь 10 000 продактов, проверивших по одной гипотезе. Я боюсь одного фаундера, проверившего 10 000 гипотез»
Так вместе мы сможем построить новую экономику, в которой ИИ усиливает свободных людей.
#мысли
Датаист / Гайды
AI Product Discovery: как автоматизировать генерацию идей для продуктов
Как превратить генерацию продуктовых идей из творческого хаоса в воспроизводимую систему: сигналы рынка, конкуренты, сегменты, ICP, интервью, Pain Map, JTBD, гипотезы и Lean Canvas — с ИИ-агентами на каждом этапе.
3👍12❤4🔥4