Обновить

CEO навайбкодил прототип. Почему после этого команда не обязана работать вдвое быстрее

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

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

Тема статьи была очень интересна. Но прочитав её до конца, я остался разочарован, так как ответа на вопрос из заголовка в ней нет. Вместо него - поток сознания на смежные темы, пусть и слегка причёсанный перед публикацией.

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

Я все ждал когда же статья вернется к теме - какие аргументы использовать для разубеждения "начальства", сравнение с другими психологическими манипуляциями вроде "мы семья, поэтому работайте по 12 часов", метрики по когнитивной сложности чтения лишних абстракций от LLM и потере понимания схемы работы проекта... Темы обширные и интересные, но вот статья закончилась не успев даже начаться.

Спасибо за фидбек.

С чего вы взяли, что у вас получится разубедить менеджмент? В статье четко написано, что начальство боится упустить момент, когда LLM станут сверхпродуктивными, а инфраструктуры внутри компании и опыта у команды недостаточно для их использования.

Владелец бизнеса ставит на этот сценарий своими деньгами. Это его ответственность.

Если внутри компании есть проблемы с коммуникацией, а менеджмент и разработка движутся в противоположных направлениях, то ответьте себе на вопрос, что вы делаете в этой компании.

Я дал вам взгляд с двух сторон. Вы, как одна из сторон, должны сделать свою ставку. Что будет с LLM через 5 лет, никто не знает. Прогресс в 2023-2025 годах был сумасшедший.

Я не считаю, что позиция какой-либо из сторон на 100% правильная. Да, сейчас во многих местах разработчикам ставят палки в колеса, навязывая ненужные инструменты, но это делается в качестве инвестиции. Все инвестиции приносят либо профит, либо убыток.

Главный аргумент, который разрешит ваш спор с начальством - увеличение или уменьшение профита на фоне использования инструментов.

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

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

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

Сверхпродуктивными в чем? Какую такую работу ЛЛМ может взять на себя что бы повысить доходы в разы? Что бы эта сверхпродуктивность тот хайп оправдала?

метрики по когнитивной сложности чтения лишних абстракций от LLM

Расскажи

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

Вот тут как раз с точностью наоборот.
Для эффективного использования ллм-ок нужны опытные(в том числе с опытом ревью) и (желательно) придирчивые к коду и архитектуре разработчики.

Так это вы про эффективное использование. Про то, как в серьёзном проекте их задействовать. А в комменте выше про «некоторые приложения на коленке»

По вашему описанию, эти придирчивые к коду и архитектуре разработчки, должно быть, это те самые дяди с тех.собесов, перед которыми стоит задача вогнать в стресс кандидата, но тут есть нюанс, весь их скилл, как правило упирается в задачи с собесов(

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

Наверное, поражает масштаб этого психического расстройства, когда плохой код, сгенерированный ИИ идёт в прод. Сейчас этим занимаются буквально все: крупные компании (включая бигтех), средние компании. Мелкие компании. Смотрю вакансии: ни одной истории с прошлого года «мы сделали стартап, вышли на самоокупаемость, набираем инженеров». Зато, куча запросов «мы ищем инженера, который умеет всё: фронт, бэк, приносить кофе, заправлять принтеры. Главное требование - вайбкодить, но так, чтобы это работало. А то нам уже навайбкодили, и оно не работает».

Создатели ИИ регулярно обещают повышенную точность кодогенерации. Но её нет. Всё зафиксировалось на уровне кода от ChatGPT 4, и если есть какие-то качественные изменения, то они не существенные. Зато, есть количественные изменения: в агентском режиме LLM может быдлокодить в 10 раз быстрее. Может буквально вывалить из кишки целый проект. Также, стоит напомнить, что ИИ до сих пор не окупает даже своё размещение на серверах, и доступен массово только потому, что в него инвестируют. Если инвесторы устанут от лжи создателей, ИИ останется доступным только для бигтеха и крупных фирм.

Опытные инженеры говорят: «одна из наших команд за несколько месяцев навайбкодила проект, который раньше делали несколько лет». Я спрашиваю: «он проходит все продовские тесты по load, e2e»? Мне говорят: «нет, но уже готова MVP, которой пользуются демо-юзеры». Разумеется, они не уточняют: сколько ещё времени необходимо для вывода решения в прод? Если оно будет сопоставимо с несколькими годами разработки в сумме, то в чём преимущество LLM? Действительно ли LLM ускорили разработку, или просто новая команда использовала готовое решение задач старой команды, которая тратила месяцы на построение определённой архитектуры и поиск решений для ранее не исследованных алгоритмов?

В большинстве случаев, кода человек говорит об успешном внедрении ИИ, мы не задумываемся над процентом работы, который выполняет ИИ. К сожалению, даже если ИИ выполняет 40% работы, ничто не мешает написать в отчёте, что было выполнено 80% работы. Менеджмент преуменьшает роль и вклад человека в работу с ИИ.

Если же мы говорим об AI-solo или AI-first решениях, то нас пытаются убедить в том, что эти решения уже находятся в промышленной эксплуатации. Проблема в том, что если мы начинаем углубляться в этот вопрос, то выясняется, что либо решение - демка, которой далеко до ПЭ, либо решение уже отклонено бизнесом из-за невозможности выполнить функциональные и нефункциональные требования, либо решение было переписано руками разработчиков на 80% прежде, чем попасть в ПЭ. Либо никто никогда не видел этого решения кроме автора, написавшего о нём. Проблема проектов, сгенерированных ИИ: они либо удобно делаются для внутреннего использования, либо они не рабочие.

Как правильно сказал автор статьи, мы уже используем ИИ в своей работе. ИИ помогает старшим разработчикам писать код быстрее. Особенно, они незаменимы, когда нужно создать много сходных классов и функций. Например, мне может понадобиться много объектов Repository, Pydantic схем, тестов. ИИ сэкономит мне несколько дней работы на рутине. И это прекрасно. Но нет ничего прекрасного в том, что ИИ пытаются использовать для замены разработчиков. При этом, адекватные люди видят, что ИИ так не работает. Видят, что ИИ, скорее-всего, не будет так работать ближайшие лет 20, как минимум. И, всё-равно, соглашаются с дурачками, которые кричат, что нужно только приложить этот ИИ к заднице другим местом (например, развернуть ансамбль из агентов), как ИИ тут же оставит без работы всех программистов разом! Ансамбль - это, конечно, хорошо. Но, как писал когда-то Крылов:

«Чтоб музыкантом быть, так надобно уменье

И уши ваших понежней, —

Им отвечает Соловей, —

А вы, друзья, как ни садитесь,

Всё в музыканты не годитесь».

Согласен. Я вообще в шоке, как все забыли вдруг про качество разработки. Типа это не важно. Только стандарты качества не на пустом месте возникли. В первой главе книги "Чистая архитектура" очень хорошо написано зачем это бизнесу. Вот когда у вайбанутых решений вылезут проблемы поддержки начнут правильно юзать инструмент ллм - генерация шаблонного кода, тесты, бойлерплейт, документация, но не для разработки блин проектов..

Если эти решения дойдут до поддержки. Пока что я вижу пустоту в индюшатнике: полное отсутствие взлетевших стартапов, если только этот стартап сам не предлагает ИИ как сервис. Хотя, это очень удачно маскируется мировым экономическим кризисом.

А так, если ИИ-соло написанные решения дойдут до поддержки, боюсь, что ради добавления фичи их придётся с нуля переписывать. Разумеется, ИИ может сделать это быстрее, чем программист. Но недостаточно быстро.

Цель подобных переводных "статей" обозначить ложные ориентиры в проверенную и отлаженную практикой технологию разработки ПО. Верификация чужого программного кода, разработанного человеком или созданного автогенератором, по сложности (начиная от 1000 строк ЯП) сложнее, чем написание его самостоятельно. И не каждый разработчик сможет ее выполнить квалифицированно, тут важен прежде всего личный практический опыт в программировании. Помимо проверки кода требуется его документирование и доработка на надёжность. Например, на уровне отдельных процедур проверка на допустимость значений вх. параметров, обработки исключений с записью их в системный errors.log и многое чего другого, не говоря о выдерживании принятого в компании стандарта на программный код.

Значительно было бы лучше все наоборот: код разработанный человеком проверяет автомат-ИИ и выявляет в нем ошибки. Это действительно ускорило бы процесс разработки кода и повысило его надежность. Но фундаментальная проблема моделей ИИ построенных по технологии LLM заключается в том, что они НЕ понимают смысла создаваемого им контента. Применительно к обсуждаемой теме это смысл генерируемого программного кода. Ибо их "мышление" НЕ моделирует 1в1 процесс восприятия и логического мышления человека, а, упрощенно говоря, представляет алгоритмическую генерацию контента либо по уже известному примеру, либо путем конкатенации предыдущего контента со следующим, который выбирается согласно настройкам вероятностных корреляций между параметрами модели, сформированными по обучаемому материалу. Для того, чтобы модель-ИИ понимала смысл своего результата, необходимо чтобы она понимала смысл того чему её обучают.

Но это вовсе НЕ означает, что автогенераторы программного кода надо напроч игнорировать. Тут дело личного вкуса и условий в которых их можно применять с умом. Скорее всего эта технология для повышения качества результата будет специализироваться под конкретные задачи. Но профессиональные архитекторы и разработчики ПО никуда не денутся.

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

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

Пробовал и от этого мысли еще печальнее. Я же не вещь сам в себе, я для бизнеса довольно ограниченная функция автоматизации и я вынужден взаимодействовать с людьми меня окружающими и выбор этих людей и раньше то был ограничен в смысле специалистов, а сейчас тем более. Я на некоторых людях вижу вырождение их профессиональных навыков в "операторов ЛЛМ" прям осязаемо. Люди в моем окружении уже прям сейчас выдают продукт, которые они не могут ни валидировать, ни в итоге успешно использовать. Пока это не приводит к значимым фейлам, но тенденцию я вижу.

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

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

А что вы предлагаете? Заняться луддизмом?

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

Отрицательный результат на НЕ здраво мыслящих гарантирован абсолютно.

Во первых это профессионально обоснованная критика, а не голое и абсолютное отрицание всего. Давайте против нее свои контр аргументы потом и потолкуем. Если их нет, то луддизм будет с вашей стороны против обоснованной критики.

Если к аналогиям, то мы видим толпу, гонимую страхом потерять целесообразность работу, стремящуюся как минимум свою сотню баксов из зарплаты заплатить за продолжение бытия в тренде.
С каждого офисного по 100 баксов уже не плохо. Это определенно станет трендом и уже становится трендом, судя по моим знакомым. Конечно не полная выборка, но что вижу. На таком объеме, подгоняемом громадными финансовыми вливаниями, я не вижу у себя ресурсов ни разговаривать с каждым, ни пытаться из себя строить Будду в попытке обернуть тенденции вспять. Могу продать им лопату для копания им себе счастливого будущего, к слову, чем скорее всего и займусь в ближайшие несколько лет.
А там куда кривая вывезет. Выкопают светлое будущее - отлично. Не светлое будущее - ну хоть на лопатах штаны себе поддержим.

Подобные рассуждения в той или иной вариации приходилось слушать от ИИ-оракулов и 60, и 50, и 40 лет назад. Пластинка долгоиграющая оказалась.

Детский сад какой-то. "Ты - луддист", "Нет, ты - луддист". Давайте, начнём с того, что я не выступаю против технологии. Я выступаю против откровенно мошеннических действий, прикрываемых этой технологией. Против глупости людей, которые пытаются заткнуть этой технологией любую щель. Выступаю здесь - в сообществе, открыто публикуя в комментариях свои суждения. А вот вы провоцируете, когда говорите, что этот подход - есть проявление покорности. Это не так. Бизнес делает ставку на ИИ потому, что надеется, что ИИ заменит бизнесу дорогой штат IT-шников. Кризис способствует тому, что бизнес уже сейчас вкладывается в замену айтишников на ИИ. Наше дело - публично сказать, что эта затея до добра не доведёт. А вот послушает нас бизнес или нет - его проблемы. Мне, как минимум, легче от того, что коллеги наблюдают ту же ерунду, что и я, и что я такой не один.

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

Не все профессии из этого списка - заменяемые на ИИ. Я бы сказал, что часть бухгалтеров, часть аналитиков и процентов 80 - творческих профессий. Но, например, творчество сейчас и так переживает кризис. И без ИИ. Аналитики останутся, но их будет гораздо меньше. Скорее-всего, финальное решение оставят за человеком. Юристы всегда работают с людьми. Перевести их работу в оффлайн невозможно. У инженеров слишком велика цена ошибки. Не сомневаюсь, что дебильные попытки дать инженерное решение на откуп ИИ приведёт к нескольким трагедиям, и там будет законодательный запрет в большинстве стран на разработку инженерных систем искусственным интеллектом. Переводчики бывают разные. Те, что переводят на слух при личном общении, точно останутся. Те, что переводят тексты, скорее-всего, сильно потеряют в численности. Руководители тоже должны принимать решения, и их не отдадут на откуп ИИ. А если отдадут, то после нескольких инцидентов вернутся к классической схеме управления.

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

Я предложил коллеге (на примере своего коммента) занять позицию конструктивного критика и просветителя. Это не луддизм, а профессиональная позиция по обсуждаемой в статье важной темы. Вы, уважаемый, возможно поняли, что я призываю в том числе и к НЕ обоснованной профессионально голосовой критике, т.е. заняться луддизмом. Это не так.

Бизнес думает, что ИИ это хорошо т.к. сейчас хайп, раздутый конкуренцией производителей ллм и менеджмент не разбирается. Но профи видят, какую лапшу оно генерит и как может все перепутать и себя запутать заодно. Одно чинит ломает другое. Для бизнеса такое ПО с ростом будет становиться обузой и проблемой (больше “тихих” багов, сложность поддержки, изменения, добавления новых фич итд), а код не так просто будет откатить уже… Вот тогда будет новый хайп и тренд с ориентацией на качество, т.к. это деньги.

А меня признаться удивляют люди, которые говорят что ИИ пишет "плохой", "некачественный" или "небезопасный" код. А на чем, простите, этот самый ИИ обучался?

ИИ - это зеркало, в котором отражается современный уровень ИТ. ИИ пишет код на уровне медианного разработчика.

Есть много разработчиков, которые пишут хуже чем ИИ. Разнообразного говнокода я в жизни повидал (а на старте карьеры признаться и написал) более чем достаточно, и его авторы - люди. И этот говнокод - в проде.

Где я говорил, что разраб-говнокодер это хорошо? Это тоже самое, что и ИИ говнокодер. Какая разница кто эту лапшу пишет.. Тут очень точно заметили “ии ускорил написание говнокода” - в этом сомнений нет.

Есть понятный и очевидный тезис, с которым никто не спорит: Хороший код - хорошо, плохой код - плохо. Те кто пишут плохой код - редиски (неважно кожаные они или кремниевые). Менеджеры которые выпускают плохой код в прод - редиски.

Это ок - за всё хорошее и против всего плохого.

А вот дальше часто происходит нечто странное. Говорят "ИИ пишет плохой код". А что имеют в виду?

  1. Первый вариант - "Существует код, который одновременно написан ИИ и плох". Ну существует, и что? Существует код, который написан человеком и плох.

  2. Второй вариант - "Весь код, написанный ИИ, плох". Это очевидное вранье.

  3. Третий вариант - "Доля плохого кода, написанного ИИ (относительно общего объема кода написанного ИИ) выше, чем доля плохого кода написанного людьми (относительно общего объема кода написанного людьми)".
    Этот вопрос требует исследования, я убедительных доказательств не видел. Сравнения в основном выполняются по публичным репозиториям, а самый шлак обычно в корпоративном секторе и недоступен для сравнения.

То есть мы (не персонально вы или я, а программистское сообщество в целом) не факт что имеем моральное право стоять в белом пальто и говорить "ИИ пишет плохой код". Может быть пальто не такое и белое?

Все это демагогия. Я вижу, что генерит мне ллм и сколько надо сил приложить, чтобы сформировать нужный контекст, архитектуру, потом все заревьюить и исправить. Это ничего общего не имеет с вайбкодингом и не далеко от разработки руками по времени, а по процессу сильно проигрывает (постоянное раздражение от ревью тупости). Чистый вайбкодинг - 100% говнокод. Все проекты вайбкодеров, которые видел - дно, где тупость на тупости, отсутствие безопасности, загрузка всех данных в память, все на дубликатах (даже на фронте шаблона общего нет - все на каждой стр продублировано), все что можно хардкодится и тд ну прямо такой хороший говнокод первых шагов начинающих. Единственное отличие - все наглухо фоллбэчится, чтобы ты никогда в жизни не поймал 500 ошибку и твое приложение жило на тихих багах. Я такое в своих проектах не использую и никакому бизнесу не пожелаю т.к. с ростом это будет все большая проблема, где единственный вариант - переписать с нуля.

Вообще-то для профессионала (не путать с кодером! ) НЕТ такого понятия как "писать код". Есть понятие "разрабатывать программный код". Писать можно письмо, статью, комментарий или даже ниписать книгу. Давно (полвека уж точно) у профессионалов сложилась аналогия 1в1 проектирования и разработки ПО как сложного технического изделия. Все стадии разработки и жизненные циклы повторяются 1в1. Разработка кода программой единицы (процедуры, функции) соотносится с изготовлением рабочим конкретной детали по разработанному технологом технологическому процессу. Автогенератор выдаёт программный код. Он может быть верным, а может и содержать ошибки. Это может определить только его тщательное тестирование и время эксплуатации. Есть один нюанс, который отличает программный код от детали. Даже если он прошёл успешное тестирование, все равно требуется его верификация и документирование алгоритма его работы для будущей возможной модификации или нахождения вдруг возникшей ошибки. Разобраться в чужом программном коде из более чем 100 строк ЯП далеко не тривильная задача, тут прежде всего требуется большой практический опыт программирования и не КАЖДЫЙ эту работу сможет выполнить профессионально. А главное тоже требуется время. Если вы используете автогенераторы для своих личных целей никто вас не отговаривает делать это. Как говорится, бог в помощь. Если же разрабатывается серьёзное ПО с десятками и сотнями тысяч строк на ЯП, то тут "на арапа" с автогенератором проскочить будет не так просто. Допустим, что он вам все "сгенерит" в несколько раз быстрее, чем бы разрабатывалось вручную. Собрали, прогнали, вроде все работает, Ок. Через некоторое время (скажем через полгода) выплывают ошибки (без них не бывает даже у автогенераторов), как их будете искать и устранять если у вас на руках от вайб-кодера на память остались лишь задания-промпты для автогенератора? Это конечно при условии, что верификации и документировании не было. Найти ошибку в недокументированном программном коде и/или его модифицировать будет не так просто. Повторяю, что эту работу НЕ каждый сможет выполнить качественно. Без верификации и без доработки под свои стандарты ни одна ответственная ИТ компания сгенерированный программный код использовать не будет. Поэтому довод в пользу резкого сокращения общего времени разработки ПО при "написания кода" автогенератором сомнителен. Да, "сгенерится" все быстро, но сколько времени и какой квалификации потребуется чтобы во всем этом разобраться и довести до ума.

CEO навайбкодил прототип. Почему после этого команда не обязана работать вдвое быстрее

Потому что пусть сам это и поддерживает в проде. Стабилизирует, фиксит, тестирует, дебажит, деплоит и все с этим связанное.

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

Публикации