Очевидные (и не очень) последствия изобилия кода
Окей, мы поговорили о том, что пилить, если можно запилить что угодно, и как при этом не потерять понимание —> давайте теперь порассуждаем про очевидные и не очень последствия изобилия кода.
Теренс Тао приводит интересную аналогию - изобилие еды - что изобилие всяко лучше, чем дефицит, и мир точно стал лучше. Но оно же привело и к ряду проблем - ожирение, новые заболевания и тп - и нам пришлось адаптироваться к этому. С софтом, имхо, тоже потребуется перестроить многое вокруг производства. Некоторые мысли по теме:
1) Нагрузка на инфраструктуру увеличивается в разы. У нас месячного лимита GitHub Actions стало не хватать, а Anthropic вообще написал свою систему контроля версий Scion : в монорепозиторий вливается 30K+ изменений в день, и архитектура не совсем была готова к нагрузке от always on агентов. Больше кода —> больше сборок, проверок, хранения, пуллов и пушей и тп. Продолжите список элементов инфраструктуры, которые начинают трещать от изобилия кода?
2) Приходится менять процессы проверки и выпуска. Если каждое изменение ждёт человека, очередь растёт вместе с аутпутом агентов. Команда Claude Code уже разрешает мержить часть низкорисковых изменений без обязательного человеческого ревью. Постепенный роллаут и откат - тоже в ту же тему. Если помните, мы как раз разбирали это на Фестивале Фонарей. Какие еще процессы надо поменять, чтобы пожинать плоды AI разработки, и при этом не разломать все к чертям?
3) Неожиданно для меня пришли к выводу, что может появиться целый сервис по удалению софта. Признавайтесь, у кого было так, что после очередного хакатона забыл погасить сервак и потом получил $1000 счет на клауд? :) . Признаться, я иногда сам не помню, где что осталось. При этом полезные старые версии, поддержку которых раньше было экономически нецелесообразно продолжать, теперь вполне можно.
4) Меняется круг конкурентов. Теперь сотрудник нашего лучшего клиента может вполне собрать приемлемое решение на пару с дружбаном. Бухгалтерская или логистическая компания может включить такой софт в свою основную услугу и покрывать стоимость из её дохода. У вендоров появляется целый новый пласт конкурентов с другой экономикой, которому не обязательно зарабатывать на продаже софта. Что тогда такое продукт и его конкурентное преимущество - экспертное знание? данные? отношения с регуляторами? бренд? Как это дело обстоит в индустрии производства еды? o__O
5) Выбор софта становится отдельной задачей. Если его предложение вырастет в 10-100 раз, найти подходящее, проверить и встроить в свой процесс тоже будет стоить времени и денег. Стоит ожидать появления эдакого YouTube для приложений, и возможно инфлуенсеров :) А тот, кто помогает выбирать, может получить больше влияния на то, каким продуктам достанутся пользователи.
При этом выбирать и использовать софт будут и агенты. Им тоже нужно найти инструмент, понять, для чего он подходит, вызвать его и проверить результат. Возможно, частью приложений мы будем пользоваться, даже не зная их названий - их будет подбирать дружбан под нашу задачу.
Мой критерий успеха из первого поста не меняется: скольким людям продукт улучшил жизнь и насколько. Но если полезный софт можно собрать самому или получить вместе с другой услугой, польза для клиента уже не обязательно превращается в выручку отдельного софтверного вендора.
Отсюда главный вопрос: если наш клиент сможет сам собрать приемлемый аналог вашего продукта, за что он всё ещё захочет платить вам?