Когда я что-то осознаю, мне хочется об этом рассказать. Здесь делюсь мыслями и открытиями - про технологии, предпринимательство и инвестиции.
Max Votek @Mkitt - предприниматель, сооснователь Customertimes, инвестор.
linkedin.com/in/max-votek
Post #543
1.81K

Кто будет чинить то, что накодили агенты
McKinsey в State of AI 2026: 32% компаний отказались минимум от одной покупки софта, потому что собрали нужное сами с помощью coding agents.
Из этого делают вывод, что следующие на очереди после SaaS - интеграторы.
Я вижу это чуть иначе.
Starbucks строит замену системе Microsoft для учёта запасов и инструменту IBM для обслуживания оборудования. Экономия $30 млн техбюджета в год, из них около $10 млн на самом софте. Всего компания тратит на софт $400 млн ежегодно. Запуск на все кофейни в конце 2027, после тестирования.
Сроки тут важнее суммы. Код агенты напишут за недели. Остальные полтора года уйдут на то, чтобы связать его с кассами, складом и данными с оборудования в тысячах кофеен и ничего не сломать по дороге.
Клиент не будет интегрировать это сам. Не потому что не хочет, а потому что не может.
Собрать модуль с агентом стало дёшево. Встроить его в ландшафт - нет.
Нужно знать, почему и на каком складе есть исключение из общего правила, что случится с проводкой, если агент поправит остаток, и какая настройка 2011 года сломается от нового поля.
Это знание на стыке техники и бизнеса. В документации вендора его нет. В промпт оно не помещается, потому что клиент не знает, что спрашивать.
Я писал про агента-архитектора SAP, который читает настройки за двадцать лет и рассуждает о последствиях изменений. Он делает нас быстрее. Но вопросы ему задаёт человек, который эти двадцать лет внедрял.
Есть и вторая часть, о которой в заголовках ни слова. Всё, что накодили агенты, надо тестировать, поддерживать и обновлять.
Код подешевел, поэтому его станет больше: больше кастомных модулей, больше интеграций между ними, больше мест, где ошибка сработает сразу в тысяче магазинов.
Держать команду поддержки под каждый самодельный модуль клиент не станет. Дешевле отдать это тем, кто такое уже сопровождает.
Так что часы никуда не деваются. Умирают часы за типовую настройку, которую агент делает за десять минут.
Часы человека, который понимает и таблицы, и склад, и что случится с закрытием месяца, дорожают.
Клиент платит за них больше, если результат виден в его P&L(отчёт о прибылях и убытках): меньше пустых полок, меньше простоя оборудования, закрытие месяца на два дня быстрее. Ставка растёт вместе с тем, за что ты готов отвечать.
Build-vs-buy - плохая новость для производителей ПО. Для интеграторов это другое: переход от типовых настроек и простого программирования к глубокому погружению в бизнес клиента, к тестированию и поддержке - конечно, с помощью агентов.
Мой прогноз такой, что через три года самая большая строка в их выручке - сопровождение того, что клиенты собрали сами или придумали с агентами и отдали на доработку.
@maxvotek | linkedin | substack
McKinsey в State of AI 2026: 32% компаний отказались минимум от одной покупки софта, потому что собрали нужное сами с помощью coding agents.
Из этого делают вывод, что следующие на очереди после SaaS - интеграторы.
Я вижу это чуть иначе.
Starbucks строит замену системе Microsoft для учёта запасов и инструменту IBM для обслуживания оборудования. Экономия $30 млн техбюджета в год, из них около $10 млн на самом софте. Всего компания тратит на софт $400 млн ежегодно. Запуск на все кофейни в конце 2027, после тестирования.
Сроки тут важнее суммы. Код агенты напишут за недели. Остальные полтора года уйдут на то, чтобы связать его с кассами, складом и данными с оборудования в тысячах кофеен и ничего не сломать по дороге.
Клиент не будет интегрировать это сам. Не потому что не хочет, а потому что не может.
Собрать модуль с агентом стало дёшево. Встроить его в ландшафт - нет.
Нужно знать, почему и на каком складе есть исключение из общего правила, что случится с проводкой, если агент поправит остаток, и какая настройка 2011 года сломается от нового поля.
Это знание на стыке техники и бизнеса. В документации вендора его нет. В промпт оно не помещается, потому что клиент не знает, что спрашивать.
Я писал про агента-архитектора SAP, который читает настройки за двадцать лет и рассуждает о последствиях изменений. Он делает нас быстрее. Но вопросы ему задаёт человек, который эти двадцать лет внедрял.
Есть и вторая часть, о которой в заголовках ни слова. Всё, что накодили агенты, надо тестировать, поддерживать и обновлять.
Код подешевел, поэтому его станет больше: больше кастомных модулей, больше интеграций между ними, больше мест, где ошибка сработает сразу в тысяче магазинов.
Держать команду поддержки под каждый самодельный модуль клиент не станет. Дешевле отдать это тем, кто такое уже сопровождает.
Так что часы никуда не деваются. Умирают часы за типовую настройку, которую агент делает за десять минут.
Часы человека, который понимает и таблицы, и склад, и что случится с закрытием месяца, дорожают.
Клиент платит за них больше, если результат виден в его P&L(отчёт о прибылях и убытках): меньше пустых полок, меньше простоя оборудования, закрытие месяца на два дня быстрее. Ставка растёт вместе с тем, за что ты готов отвечать.
Build-vs-buy - плохая новость для производителей ПО. Для интеграторов это другое: переход от типовых настроек и простого программирования к глубокому погружению в бизнес клиента, к тестированию и поддержке - конечно, с помощью агентов.
Мой прогноз такой, что через три года самая большая строка в их выручке - сопровождение того, что клиенты собрали сами или придумали с агентами и отдали на доработку.
@maxvotek | linkedin | substack
- ❤ 27
- 👍 22
- 🔥 4


