Обновить

Вы считаете ИИ-ускорение неправильно, сливая бюджет в трубу, пока 7 из 10 проектов умирают ещё на этапе пилотов

Уровень сложностиПростой
Время на прочтение9 мин
Охват и читатели7.2K
Всего голосов 12: ↑10 и ↓2+10
Комментарии10

Комментарии 10

Очень зацепило, что вы считаете не «грязное ускорение», а закрываете задачу только после вычищения галлюцинаций. Это, по сути, самый честный кусок методологии, потому что рынок обычно меряет до первого happy path, а не до production-ready результата.

Но тут сразу вопрос: как вы нормализовали quality cost между командами? Потому что у одних ревьюер жёсткий и разворачивает ползадачи, а у других — «ну вроде ок». Отсюда разброс от -2x до 4x по дебагу?

Обычно компании надеются усилить джунов иишкой. А по факту LLM, кажется, сильнее бустит людей с хорошим фильтром качества, чем людей с дефицитом фундаменталки. Было бы очень интересно увидеть отдельный разрез по seniority: у вас эффект реально рос вместе с уровнем исполнителя или это пока скорее качественное наблюдение?

В целом, всю историю разработки такая корреляция соблюдается.

Когда придумали ассемблер, разработчики переживали: "о, теперь домохозяйки будут код писать". В итоге порог входа стал сложнее, повысились требования к компетенциям.

Когда придумали языки программирования высокого уровня, разработчики переживали: "о, а вот в этот раз домохозяйки точно будут писать код за нас". В итоге порог входа стал еще выше, материалы для обучения стали кратно сложнее.

Когда придумали фреймворки, разработчики снова переживали: "о, в этот раз точно код любой чайник сможет писать". В итоге порог входа стал еще выше, помимо знаний языков программирования пришлось изучать фреймворки, и появились аж специалисты одного фреймворка (ярко выражено в питоне), которые непригодны для работы даже на том же языке, но с другими фреймворками.

Когда придумали нейросети, снова мы проходим стадию переживания: "а может быть в этот раз нас заменят". Нет. Нет никаких оснований считать, что что-то в этой логике изменится. Исходя из предыдущего опыта - порог входа станет еще выше, требования к навыкам станут еще больше, что как раз говорит о прямой корреляции с вводным уровнем компетенции для использования этого инструмента.

Информация, как и любое явление - требует равновесной среды (где-то убыло, где-то прибыло). То есть есть парадокс: чем проще инструмент, тем он сложнее. Потому что надо уметь отвечать на вопросы: "а что такое правильно?", "а что такое эффективно?", "как отличить вообще галлюцинацию от истины?". В этой связи, для использования "простого" ИИ инструмента требуются БОЛЬШИЕ компетенции на старте внедрения, нежели ранее без его использования. Это вроде бы называется "Парадокс автоматизации", если правильно помню - здесь он тоже применим в полной мере.

Но сразу видно, где у них слабое звено в команде. Это QA (ИИ очень любит запечатывать баги в проектах, или предлагать неоптимальные решения, потому что фокус смещен на покрытие тестами - а не на соответствие логики кода изначальным требованиям) и DevOps (ни разу на моей практике ИИ не смог написать правильную конфигурацию без лишних/неоптимальных инструкций, то есть ИИ действует как джун девопс - не строит оптимальную конфигурацию, а раз за разом тянет "из закромов" её с лишними записями, в итоге где в тех же k8s чартах или docker файлах до 90% лишнего кода, не говоря уж о шагах CI).

Есть ощущение, что ИИ опять же работает тогда, когда у команды уже есть натренированность - а когда ее нет, то сначала пару месяцев провисания и только потом буст. Интересно, как это у вас)

Сразу видно, что вы реально тестируете, а не гоняетесь за хайпом. Особенно интересно про галлюцинации в Native, теперь понятно, почему нельзя слепо доверять ИИ.

Короче, прочитал за вас, смотрите, если у вас порядок в процессах — ИИ ускоряет процессы. Если у вас бардак в процессах — ИИ ускоряет бардак. Cпасибо за внимание ;)

Так-то самый сильный вывод статьи — «хаос автоматизировать нельзя». Многие как раз почему-то сначала внедряют ИИ, а уже потом думают о процессах.

Потеря контекста. В анализе детальные ТЗ по экранным формам и интерфейсам быстрее писать вручную. ИИ плохо удерживает визуальный контекст и логику сложных UI-взаимодействий.

Claude Code неплохо справился с генерацией UI-форм на Qt. Исходник - скриншот приложения в jpeg. Сложной логики не было, но сам факт - на входе скриншот, а на выходе готовая форма (почти) - далее мелкие правки уже готового, созданного ИИ Qt приложения.

Не представляю как у вас так получается всех, я сколько не кормил скринов дизайна клоду, у меня вообще получаеться адовая дичь..

Ставил в режим рассуждения и на максимум потребление токенов (не помню как настройка называется), и пыхтел он где-то примерно один час - но выдал таки работающий результат.

У Dart и Swift — худшие показатели в AutoCodeBench, что в принципе искусственная метрика, но как бы подсказывает, что обобщать на «ПО» ваши выводы — тоже так себе идея.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации