Автор призывает трезво смотреть на ИИ в разработке: где он помогает, а где мешает
Автор призывает трезво смотреть на ИИ в разработке: где он помогает, а где мешает Автор колонки на Хабре рассуждает о хайпе вокруг ИИ в разработке. Его отправная точка — типичная история: человек за два вечера с помощью ИИ собрал работающий магазин кормов для кошек и объявил новую эру. Автор не спорит, что инструмент годный, но замечает: настоящий тест наступит позже — когда после правок что-то незаметно сломается, например после добавления скидки пропадёт самовывоз. Он предлагает «работникам айти» самим осмысленно экспериментировать с ИИ в рамках своих ограничений: понять, где модели можно отдать работу, где проверять каждый шаг, а где дешевле сделать самому. Важно и то, когда способ перестаёт работать: если помощник третий раз исправляет последствия собственного исправления — это тоже результат эксперимента, хоть о нём и неохотно рассказывать на фоне историй о магическом успехе. За требованием «ускорить команду» автор регулярно видит желание просто научиться планировать работу: обещанные четыре недели превращаются в восемь, и об этом узнают в последний день четвёртой, когда клиентам уже пообещали и рекламу заказали. При этом задача часто застревает в согласованиях и зависимостях от других команд, а ускорять собираются именно написание кода. Под одним требованием скрываются разные проблемы, но средство уже выбрано: «нужен ИИ». Опасение автора: ИИ могут использовать как способ ничего не менять в процессах — раньше задержки лечили кранчами и работой по выходным, теперь появился участник, которому выходные не нужны. Он предлагает вместо этого донести до менеджмента, что перед разгоном конвейера фич стоит разобраться, что именно пытаемся ускорить и почему проблема именно в скорости. Сложность в том, что технические аргументы вроде «получим неподдерживаемую мешанину» руководители часто воспринимают как нежелание работать, особенно если экономия уже нарисована на слайде. Отдельный пласт критики — консультанты и ораторы на форумах, которые рисуют картины замены 70% людей двумя подписками на ChatGPT и Claude по двадцать долларов. Руководителям приятнее слушать обещания экономии и роста, чем просьбы притормозить, — особенно когда отчитываться нужно в конце года, а рост стоимости поддержки случится уже за пределами отчётного периода. Автор задаёт и вопрос устойчивости: что будет с командой, изначально строящей процессы вокруг ИИ, если стоимость моделей вырастет в десять раз, нужная модель станет недоступна или поставщик введёт ограничения? Сколько будет стоить «ИИ-переезд» и умеет ли его делать хоть кто-то? Ответ стоит найти до того, как людей, способных работать без внешнего сервиса, посчитают избыточными. Ещё одна проблема — люди. Программистам, которым нравится сам процесс поиска решения и разбора, сложно весь день ставить задачи генератору и проверять результат. Если такие специалисты уйдут, некому будет разбираться в большой системе, которая не перестаёт накапливать сложность от того, что её стало легче дописывать: зависимости, исключения и старые договорённости остаются. Без них не определить, дал помощник правильное объяснение или лишь правдоподобное. Автор советует скептичнее относиться к историям успеха — например, к рассказам о конвейере из десятков агентов, «запустивших 100500 продуктов»: что это за продукты, окупают ли они хостинг и трафик, что с ними через несколько месяцев эксплуатации? Ценен и опыт тех, кто отчаялся получить от ИИ приемлемый код: где инструмент помог, где начал мешать и когда следовало остановиться. По мнению автора, ИИ — мощная технология уровня паровой машины, но её нужно использовать с пониманием ограничений, а не прикручивать ко всему подряд. Источник: https://habr.com/ru/articles/1087284/