Комментарии 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, что в принципе искусственная метрика, но как бы подсказывает, что обобщать на «ПО» ваши выводы — тоже так себе идея.

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