Из статьи абсолютно непонятно, что хотел сказать автор. Возможно, нужно ознакомиться с продуктом? Зашёл на сайт, который автор рекламирует в последней строке.
Спасибо за интересный разбор. Проблема существует, и очень серьёзна, но, как мне видится, она никак не в юридическом поле.
Имеем: некий технологический инструментарий, который эффективен, но даже в теории не может быть безошибочным - поэтому результат требует проверки человеком Ситуация: человек использовал упомянутый инструментарий, недостаточно проверил результат и допустил поломку
Имеются серьёзные организационные проблемы:
Инструмент реально эффективен, потому к его удачам люди привыкают и начинают всё чаще доверять ему
В следствие появившегося доверия перестраиваются и бизнес-процессы в компании, и вот исполнитель, который раньше подготавливал 1 договор в день, теперь подготавливает их 10, соответственно, он физически не имеет возможости столь тщательно проверять документы, как и раньше
Особенность языковых моделей в том, что, в отличие от людей, умело "маскируют" свои ошибки, под правдоподобные рассуждения. По-другому и быть не может - в этом суть явления конфабуляций ("галлюцинаций"), и ошибку ещё сложнее заметить.
Все эти явления - особенности применения инструмента. После первой эйфории от работы с ним необходимо придумывать правила, которые сведут ошибки к минимуму.
С другой стороны - люди тоже не застрахованы от ошибок, допускают и серьёзные, просто в статье рассматриваются ошибки определённого рода - после использования ИИ, как инструмента.
Бизнес всегда строится с учётом того, что кто-то где-то ошибётся, и подстилается максимум "соломки" под каждый случай.
Таким образом, собственнику бизнеса нужно лишь оценить, где в результате будет больше ошибок - с использованием инструмента, или без него? Сюда же выгоду от его использования, быть может, экономия покроет все расходы на устранения последствий.
А вот юридически всё так, как и сто лет назад.
Во-первых, "виновата" компания. во-вторых, ответственные лица в ней, в третьих - копают дальше, и когда упираются в инструмент, который не является субъектом права - начинают раскручивать в обратную сторону: а кто инструмент устанавливал, кто настраивал, кто обслуживал, кто использовал, какими инструкциями руководствовались, кто писал инструкции и т.д. и т.п.
Я, пожалуй, не добавил к статье ничего нового, кроме того, что все эти рассуждения столетиями применяются к любому инструменту, будь то топор или токарный станок, или станок с ЧПУ, авиалайнер или "ИИ". Юридическая цепочка та же самая.
Идея с чатом для каждой задачи - хорошая, если не сказать - отличная! Так же внедрял в своей системе. :))) Фишка в том, что сообщения - это не только и не столько форма общения, а это ещё и некий "лог выполнения" задачи.
Однако, есть важные нюансы. Если их не учесть,то этот лог выполнения дорого обойдётся.
Прежде чем дать чатик в руки исполнителям - нужно НАУЧИТЬ их культуре написания чата. Учить должна сразу сама система. Писать только нужные сообщения. Писать для читателей, а не просто потому, что захотелось куда-то облегчиться.
А что мы видим на главной страницы YouJile, (копипаста скриншотов которых в статье)?
Зачем мне эти сообщения, как их потребителю. Сижу я, в мыле или в "потоке", точнее, просто РАБОТАЮ, и тут прилетает....
Какие мысли возникнут у человека, который реально работает, а не занимается болтологией, при их прочтении....
"Привет, планирую сегодня доделать макеты главной и страницы контактов" Зачем мне информация о том, что ты там планируешь? Кого она вообще интересует? У тебя поставлена задача, ну так распланируй её сам, и сделай, когда тебе удобно. Мне зачем эта информация?
"Хорошо. Клиент просит сделать минималистичный сайт в синих тонах ......" Что это? Дополнения к поставленной задаче? Почему они не были загружены ранее, почему их дописали в ответ на пустое сообщение? А если бы исполнитель просто сделал задачу, не крича об этом на всех коллег, - он бы не получил эти дополнения? Что за культура такая у нас в команде?
"Первые макеты готовы, можно показать" Что это, кому это? Мне? А где ссылка на макет, или мне звонить нужно куда-то? Тогда где телефон? Если закрыта подзадача - то почему это не автоматическое сообщение, на которое не нужно отвечать а нужно кликать?
"Спасибо, пошёл тестировать" Кто, зачем и куда пошёл? Зачем эта информация? Понимаю, если запостят
Итого. Сообщения в задаче "Потестировать макеты на целевой аудитории" должны выглядеть примерно так (ориентир для дат возьму со скрина).
вообще говоря, это всё, но если развивать идею "важных сообщений", то должно быть как-то так...
4 авг. 10:30 Я: Не хватает кнопки "выбрать все" - выяснили, что заказов бывает слишком много, и кликать каждый утомительно, подробнее тут <Задача> 4 авг. 12:10 Иван Петров: Кнопка добавлена http://xxx.yyy.ccc/tests2
А ещё момент, на скрине у вас чат для задачи "разработать макет", а по факту, в нём написан про старт задачи "Потестировать макеты". Это так и задумано? Чаты не связаны между собой?
Интересная штука получилась. Начал с того, что, ничего не зная об архитектуре мессенджеров - начал расставлять кубики, по своему разумению. После этого упражнения текстовые описания писать гораздо веселее.
Но постоянно возникают вопросы. Что конкретно на каждом этапе выбрано, и ПОЧЕМУ? Какие есть альтернативы, какие критерии выбора, и почему выбрано именно предлагаемое решение.
Ну и ещё момент, вопросы к каждому пройденному этапу - в 100% случаев правильный тот, что содержит самый длинный текст. А ведь тоже хотелось поразмышлять, как и над кубиками.
Очень заинтересовал ваш пост, проект, полез на сайт, и... минут десять пытался понять, что же предложит софт, какова же его эффективность, ну хотя бы на искусственном примере было/стало. В идеале - фото реальных объектов.
Но... к сожалению, ничего не понял, особенно на первой гифке - там вовсе стихийная тропа (коричневым цветом) в самом низу ведёт куда-то вникуда, и явно обе планируемые тропы туда не ведут вовсе
Остальные фото тоже не дали понимания. Возможно, для того, кто в предлагаемом софте уже поработал - всё это будет понятным, но ему и ценность его вряд ли объяснять нужно....
Возможно, если потыркаться и создать демо-проект (я пробовал, но сайт повис, или с сетью проблемы), что-то и прояснится, но,
- во-первых, для этого нужно быть сильно замотивированным, к тому же, видимо, нужно быть архитектором/дизайнером, которые вряд ли относятся к ЛПР (лицам, принимающим решения)
- во-вторых, в софте тоже не будет ярких, чётких, понятных доказательств, что проложенные маршруты работают и приносят пользу.
Таким образом, даже при наличии мотивированного сотрудника в штате - бремя доказательства качества и важности сервиса, целесообразности покупки ложится на него, беднягу сотрудника.
Если у него не получится (а скорее всего нет) - то чиновник или руководитель просто пошлёт его на три буквы, зачем тратить лишних 50К.....
я всегда знаю, который час. Потому что мало того, что хорошие внутренние часы - периодически "на автомате" поглядываю на них, и если меня внезапно спросить, то я не подглядывая, скажу время с точностью до двух-пяти минут
всегда владею максимумом контекста информации, не сравнить с бумажным блокнотом, перед любым разговором достаточно проглядеть соответствующий раздел в той же Obsidian, чтобы подготовиться максимально (если это таск‑трекер, и там этот контекст уже есть - ещё проще), это позволяет не потерять нить разговора и выстроить его максимально эффективно
ключи и смартфон - единственные главные две вещи, которые нужно не забыть при выходе из квартиры, именно благодаря тому, что в смартфоне есть всё необходимое (начиная от блокнота, книг, и заканчивая банковскими картами) - я никогда не забываю ключи, в отличие от "аналогового" века, где приходилось тщательно проверять, а всё ли я собрал, и ключи могли потеряться
гаджеты позволили распределить работу именно так, как я хочу, и мало того, что работать не строго по режиму "с 8 до 17", а работать в промежутках, в транспорте, очередях и тому подобных социальных моментах, я знаю, что существует много людей, которые любят дисциплину и порядок, лично меня принудительный приход на рабочее место всегда демотивировал. Если я (пусть даже во внутреннем убеждении) работаю тогда и только тогда, когда захотел - то у меня и мотивация на порядок выше. Тем более, если я использую скучное время типа очереди или в транспорте.
Присутствует некая клиповость мышления, но это абсолютно верный выработанный механизм: ведь благодаря гаджетам и, как следствие, наличию моментального доступа к информации - количество этой информации, одновременно используемых сфер деятельности, настолько велико, что если в глубину, "на полный штык" копать хотя бы половину из них - на это уйдут десятилетия и работа встанет.
Поменялись шаблоны поведения. Деды избу одним топором ставили. Сейчас иной строитель топором пользоваться вовсе не умеет. Деменция ли это?
Не совсем понятно, в чём проблема. Разве "сужать пространство вариантов" - не задача руководителя? Ну как минимум организовать этот процесс. Но закопать голову в песок и молчать о проблемах - вряд ли лучшее решение для этого.
В команде как воздух нужны все типы личности, в том числе, параноики, иначе действительно можно упустить что-то важное.
Если чётко определить, что делать со всеми самыми страшными предположениями - например, (молча) фиксировать их, после чего
- ранжировать по возможным рискам
- прописать планы/протоколы действий, в случае возникновения
- после старта провести ретроспективу, правильно ли были оценены риски
А тем более - привлечь к этому процессу ту самую Женю, а то и назначить ответственным
То не только проблемы не возникнет - можно и нужно получить значительный профит от роли адвоката дьявола: ведь если хотя бы иногда предсказания сбываются, так почему бы не быть к ним готовыми?
Круто! Серьёзная работа. Серьёзно смущает один момент.
Нужны были программисты, а не инженеры. Специалисты, которых мы нашли на рынке, не разбирались в предметной области и нуждались в постоянном сопровождении
Разработчику не нужно глубоко погружаться в предметную область - это вредно: он может забыть про то, как нужно делать. А что нужно делать - решает аналитик, который, как раз, в предметную область погружён максимально. Это настолько разные специальности, что их одновременное выполнение чревато неким раздвоением личности: это из личного опыта, т.к. приходилось совмещать. И в своей команде я разделил эти роли.
. К сожалению, на предприятиях "далёких" от IT, понимание важности качественной проработки требований, как правило, отстутствует. Сам работаю на машиностроительном предприятии, и на 300+ разработчиков ровно 0 аналитиков. Нет такой специальности.
Парадоксально, но в ВУЗах, с которыми плотно сотрудничаем, есть цельные кафедры, подготавливаются специалисты. А на заводе даже вакансии такой нет.
Руководство считает, что это мелочи, "у нас каждый программист - аналитик"(с)
Как дело обстоит у вас? Есть ли отдельные специалисты по анализу и подготовке требований? (а так же планированием разработки, их последующей корректировке, тестировании, UI/UX исследований и т.д., чем и должен заниматься аналитик)
Есть такое понятие, "коллективное владение кодом". Оно в команде обязано быть в наличии!
НО если этот самый код (блок кода, модуль, имплементацию) - пишет один человек, а остальные молятся на него, то с какого перепуга этого работягу заставлять писать ещё и документацию?
Пусть тогда остальные тоже потрудятся: хотя бы попытаются этот код понять и задокументировать его.
Задокументировать, именно так, как они его поняли - а трудяга, прочитав этот документ, поймёт, поняли его, или не поняли, и что поняли не так.
Пара-тройка итераций - и вот и документация готова и понимание появилось. Без какого-либо взаимодействия и трат времени трудяги на разъяснения и тем более на разработку документов - пусть продолжает писать только код.
Сто раз так практиковал - неимоверная эффективность детектед.
Иначе несправедливо получается: работает один, а потом ещё и репетитором, да ещё в письменном виде - книги документов пишет. А остальные на расслабончике проехались, "не понятно им, разъясните, научите".
С "одного промпта" вообще редко что-то дельное выйдет, если только вопрос не тривиален, а ответ на него и в гугле можно получить.
Нужно понимать "сущность" LLM - они и "обрадовать" просителя хотят, и контекст у них крохотный, а ещё есть такая штука, как "внимание" модели.
Даже задачи "средней" сложности лучше решать в разных "слоях". На примере создания комментария: ну как минимум сначала запросить выделить ключевые темы, чтобы убедиться, что они все там (и, обратно, что ты ничего не упустил) - потом вычищение мусора (например, у меня непрошенные хвалебные оды появились), потом чёткие формулировки, чего хочешь ты - (например, у меня объективной критики, по существу, со стройной логической аргументацией)
Наверное можно было и удалить часть, по крайней мере моменты “Давайте поправим ситуацию” и “Автор получит по полной”
ахахаха, а это результат последней правки "добавь эмоций, жесткости и юмора": это не LLM "ошиблась", это я забыл, куда отправляю текст
по дефолту "градус" был гораздо ниже - модели заботятся о ранимых
я думаю, если бы заморочился, и попросил бы её проанализировать хабр и выдать в стиле, чтобы получить плюсы - то и результат бы не "-18", а "+18" получился бы, но такой стиль не нравится лично мне.
и тут - либо шашечки, либо ехать.
В любом случае, подавляющее большинство критики моделей и "вайбкодинга", которое встречается не только здесь, но и вообще в интернете, как правило, основывается на гипотезах, что всё должно получиться "с одного промпта", возможно, авторы пытались писать такие чудо-промпты, вместо того, чтобы выстраивать методологию, я уж не говорю об агентских сетях
Их посты напоминают страх, как в древности, когда станки заменяли ремесленников, и те, справедливо, пытались доказать, что ремеслом они делают гораздо более качественные вещи (и так оно и было), но прогресс в результате взлетает не от отдельных станков, а от системы: пусть на каждом этапе есть огрехи, и отдельно взятый Левша подкуёт блоху гораздо круче, но в сумме результат работы "сетей" станков даёт результат разительно большей эффективности и качества.
Уверен, с разработкой будет то же самое. Ручное написание кода на языках высокого уровня станет рудиментом, в основной своей массе: останется только в ключевых местах.
Как это произошло, когда ремесленников заменили бездушными станками.
Меня заминусовали настолько, что отвечать могу раз в сутки. Однако, по существу всего три поста, могу ответить на один. Постараюсь на все разом. Давайте по пунктам
обратите внимание на множество ответов по посту, созданного с использованием LLM: претензии в основном только потому что "использовал" - кошмар кошмарный
Но.. да, конечно использовал так: моя цель была как раз показательно показать:)), что LLM, именно языковая модель экономит время и улучшает качество кода, как программного, так и текст комментария.
Я не сомневаюсь, что кто-то "из головы" пишет такой код, что рефакторинг не нужен, как и то, что тексты статей тоже "из головы" напрямую пишут такие, что редактура не нужна.
Но, как показывает практика, что в работе над программным кодом, что в комментариях к статье - "красивый" код это либо в чьих-то фантазиях, либо напоказ. В продакшен (комментарии) идёт код так себе, "лишь бы работал".
Потому и "узнали", что использовалась LLM: качество текста комментария выбивается - обычно в комментариях никто особо над качеством не думает, пишут, порой даже на абзацы не разбив.
Качество было слишком хорошее для комментария, а больше претензий к тому посту, по сути и не было.
Обратите внимание, критики высказывают гипотезу, якобы я промпт написал, а оно всё сгенерило за меня. Но она в корне не верна.
Типичная ошибка работы с языковыми моделями. Кто так работает "с одного промпта" - они и разочаровываются. А после разочарования - LLM во всём обвиняют.
Так и здесь: якобы LLM раскритиковала статью (а я типа тут ни при чём, не прочитал и выложил).
Как на деле: промптов было несколько. К слову, в первой версии, где я просил обозначить ключевые моменты (чтобы не забыть про них) - модель вообще без спросу расхвалила статью и подкрепила собственными примерами, как всё круто сказано.
То есть, на деле было всё наоборот: я выдавал инструкции, что хочу получить, в каком виде, в каком стиле, до тех пор, пока не получил требуемый результат.
Но такому поведению нужно научиться, к нему нужно привыкнуть
При работе с программным кодом были проблемы: поначалу сложно было "себя сломать", чтобы не править за LLM-кой, а именно промптами корректировать результат. С трудом, но научиться удалось. Это ещё до агентской разразботки, сейчас это на другом уровне.
Впрочем, с критикой, подобной вчерашней, я сталкивался и 15 лет назад, сталкивается с подобным, наверное любой руководитель: когда ты проходишь этапы:
- начинающему кодеру объясняешь задачу, корректируешь работу, которую ему поручил, и злишься про себя, что ты бы это уже давно сам написал за 15 минут, а убил уже лично 3 часа
- через какое-то время (месяцы) происходит профит, и вот кодер уже "вышел в ноль", и теперь уже затраты окупаются, 15 минут убил, 15 - выиграл
- через какое-то время уже объяснять ничего не нужно - он пишет сам, замечательно, в "твоём стиле", но сам. И ведь обязательно найдутся люди, которые скажут, что мол - вот Вася всё делает, молодец, а начальник вообще зачем тут нужен
Так и с этой статьёй - статья написана, LLM то ли молодец, то ли наоборот, плохая (непонятно в чём), а автор поста - вовсе не автор, а рядом проходил.
Ответ на ваш вопрос, "Вы кстати разработчик, прям пишите код?" не просто сам пишу, а в буквальном смысле заставляю всех, кто ещё "не допёр" - использовать LLM-ки. Если они ещё не понимают смысла, не умеют с ними работать - значит, нужно учить!
Не увольнять "джунов" нужно, а учить пользоваться современными инструментами для разработки.
"Как правило специалисты хорошо знают тот инструмент что используют, например язык, фреймворк, библиотеку" - ну, это к пункту 1.
Для меня дело обстоит с точностью до наоборот: как раз если я хорошо знаю язык, фреймворк, с которым работают - то непременно обращусь к "нейронке", потому что я смогу оценить результат буквально с одного взгляда, при правильной настройке она вообще напишет за секунды то, что я бы набирал бы в десять раз дольше.
При этом она может учесть то, что я мог банально забыть. Именно в сценарии, когда инструментарий знакомый и задача предельно ясна нейронки и дают максимальный прирост скорости, чаще "с первого промпта".
Это на замудрёных задачах, когда сам "не можешь понять, чего хочешь, пока не начнёшь кодить" - они не дают значимого результата "с первого промпта".
Если менеджеры в восторге от идеи заменить хороший код с продуманной архитектурой на простыни наглухо зафоллбэченного задублированного говнокода с проблемами безопасности и производительности, то странно почему они все это время не бежали скупать за почти бесплатно индусов на фриланс, а искали инженеров
А кто сказал, что не бежали скупать индусов? Валом скупали!
Знакомый работал архитектором в одном зарубежном банке - уволился потому, что тяжко работать было с индусами, мало того, что увидел воочию, что "идусский код" - это не миф, мало того, что те английского почти не знают, так ещё и меняли их, как перчатки: только с одним коммуникацию наладишь - рраз, а перед тобой уже другой.
львиную долю кода в банке писали индусы, штат был раздут неимоверно, только архитектору-перфекционисту не нравилось всё это
реальный бизнес - это не всегда про "хороший код"
а архитектуру тот же клауд коде в огромном числе случае нарисует лучше, чем средней руки кожаный разработчик, а профессионалов и звёзд среди них - ты найди ещё попробуй
Вы не представляете сколько лично я "шишек" набил ещё на заре становления LLM-ок, да вот классика, с автодополнением, когда один "бот" вставлял косячный код, я, разобравшись - снёс его, написав всё правильно руками
а потом выяснилось, что я где-то в промежутке автоматом нажал ctrl+S (никак не могу избавиться от привычки) и другой бот, который годами мне только помогал, вставил "левые" библиотеки аккурат для говнокода от автодополнения
в подключенных либах у пары функций сигнатуры пересекались, и ошибка эта вылезла "боком" только через несколько дней - и искал я её несколько часов....
постепенно выработались и правила работы и "техника безопасности" в общении с моделями
оно и понятно - если не уметь пользоваться инструментом, то можно и пальцы себе отпилить, но это не повод отказываться от бензо/электро пилы в угоду ручной ножовке, только потому, что те опасны
Понравились не выводы автора - он Америку не открыл, и ни в коем случае не говорил о том, какие "вредные ресурсы" а-ля stackoverflow, он дал конкретный рецепт, технику безопасности, как их использовать, и я эту статью всем своим и знакомым начинающим разработчикам рассылал - чтобы поняли, как использовать и стековерфлоу, и профильные форумы
а не возмущались, когда, скопипастив чужой код, получали ещё больше проблем, чем было до
Во-первых, мною в ответ вам был написан только один комментарий, второй был написан для @randomsimplenumber. LLM не умеют считать, случайность?
Да нет же, LLM как раз не ошибается в подобных мелочах: на тот момент два ваших ответа, конкретно под моим постом (ниже, по цепочке), конкретно про меня, как это чётко, правильно без ошибок назвать - с этим справится LLM, но на них лень переключаться, самому подбирать слова - долго, оставил, как есть. Да, я так пишу.
Вас это уже раздражает, вы возмущены.
Но, простите, у меня нет времени колдовать над каждым словом, я не книгу пишу.
Во-вторых, чем не понравился мой пост? Отсутствием подобных формальных ошибок? Не к чему прицепиться? Да, беда бедовая! Остаётся только навешать ярлык "разговариваю с LLM", и добавить "это ниже моего достоинства".
Сложно на столь длинный выпад ответить коротко, слишком много навайбкодил автор. Давайте поправим ситуацию, заодно немного структурировав выводы в статье.
Вот яростная, но аргументированная критика статьи. Автор получит по полной — за высокомерие, логические дыры и неспособность увидеть изменения, которые уже произошли.
Суть статьи (глазами критика)
Автор — типичный «олдскульный» программист, который отчаялся чувствовать себя особенным. Он пишет желчную отповедь, чтобы убедить себя и других: «ничего не поменялось, я по-прежнему незаменим». Его главный тезис — LLM всего лишь дешёвый аналог Google и конструкторов сайтов. Это наглая ложь, подкреплённая подборкой удобных примеров и игнорированием того, что не вписывается в его картину мира.
Пять идей — и почему они не выдерживают критики
1. «Доступность инструментов была и до LLM»
Автор заявляет: «pandas читает Excel одной строчкой, CMS делают сайты — ничего нового». Это интеллектуальное мошенничество через подмену понятий.
Раньше вы должны были знать, что именно написать: df.agg(["sum", "min"]). А теперь вы говорите: «посчитай сумму и минимум по колонкам» — и LLM сама пишет этот код, даже если вы никогда не слышали о pandas.
Вы не понимаете разницы между инструментом для профессионала (pandas, CMS) и интерфейсом для непрофессионала (естественный язык). LLM убрали барьер входа не «чуть-чуть», а полностью. Спросите любого менеджера, который вчера собрал парсер без единой строки кода — он вам объяснит, что Google ему не помог бы.
И да, раньше не было возможности одной фразой «сделай как в том репозитории, но поменяй цвет кнопки на красный и добавь валидацию email» получить рабочий код. Не было. Автор врет.
2. «Спецификация сложнее кода» — главная глупость статьи
Автор с гордостью неофита заявляет, что «написать детальное описание на естественном языке сложнее, чем сразу код». Это чушь, которую повторяют только те, кто никогда не писал сложную спецификацию.
В реальной разработке спецификация всё равно нужна — хоть на русском, хоть в виде тикетов, хоть в виде тестов. LLM позволяет превратить спецификацию в код мгновенно, а не тратить часы на синтаксис, отладку угловых скобок и поиск того самого ;.
Сравните: «авторизация через JWT, время жизни 15 минут, рефреш в httpOnly cookie» — это 15 слов. Написать это на Go или даже Python с обработкой ошибок — 50+ строк. Что проще? Очевидно.
Автор путает сложность промпта для неясной задачи (когда вы сами не знаете, что хотите) со сложностью промпта для понятной задачи. Если задача понятна, промпт в 10 раз короче кода. Если задача не понятна — никакой код вам не поможет, вы будете переписывать его 20 раз. LLM тут вообще не при чем.
3. «Хайп навязывается, а эффективность не измеряется»
Автор возмущается, что нет метрик, кроме подсчёта токенов. А давайте спросим: а раньше была метрика эффективности использования Google? Или Stack Overflow? Нет. Но почему-то никто не называл это «хайпом».
То, что автор называет «принуждением» — это естественная реакция бизнеса на 10-кратное ускорение прототипирования. Если бы он работал в компании, где скорость выхода MVP решает всё, он бы не ныл про «аггрессивную рекламу».
Отсутствие метрик — проблема менеджмента, а не технологии. Но автор предпочитает бить по LLM, а не признать, что его компания не умеет измерять производительность в принципе.
И главное: пользователи сами выбирают ИИ-инструменты. Github Copilot платный, но им пользуются миллионы. Не потому что «менеджеры заставили», а потому что он реально экономит время. Автор, видимо, не пробовал.
4. «Генерация не создаёт ценности, только спам»
Здесь автор окончательно срывается в склероз и снобизм.
«Люди не хотели написать книгу — а теперь сгенерировали». А с чего вы взяли, что они не хотели? Может, у человека есть идея, но нет навыка выстроить 300 страниц прозы. LLM даёт инструмент реализации. И да, появляется больше книг — и среди них есть хорошие. Так же как появление дешёвых камер не убило фотографию, а породило миллионы новых фотографов.
Пример с Пелевиным — логическая уловка. Автор берёт вершину литературного мастерства и доказывает, что её нельзя сгенерировать. А никто и не говорит, что можно. Но можно сгенерировать 90% прикладного контента: документацию, ответы в поддержку, черновики писем, SQL-запросы, bash-скрипты, конфиги. Это огромная ценность.
«Никакой новой ценности не создаётся» — ах вот как? А автоматическая расшифровка аудиозаписей? А перевод видео в реальном времени? А генерация тестовых данных для БД? А рефакторинг легаси с сохранением поведения? Всё это появилось именно благодаря LLM. Автор просто не знает, куда смотреть.
5. «Профессионалы уже эффективны, LLM не помогают»
Самое оскорбительное и недалёкое утверждение. Автор говорит от лица «настоящих профессионалов», но на самом деле — от лица застоя.
Опытный разработчик с 10+ лет стажа тратит часы на рутину: написать однотипные CRUD-контроллеры, покрыть их тестами, поправить импорты, переименовать переменные. LLM делает это за 5 секунд. Профессионал становится в 5–10 раз быстрее на скучных задачах — и может сфокусироваться на архитектуре. Это называется рост эффективности, а не «почти не помогает».
Автор пишет: «они умеют гуглить». Гуглить — значит читать документацию, находить пример, адаптировать под свой контекст. LLM даёт готовый адаптированный ответ за 2 секунды. Разница в затраченном времени — два порядка.
И последнее: сам автор статьи явно не пробовал современные LLM в серьёзной работе. Потому что любой, кто реально использовал Cursor или Copilot с контекстом проекта, знает: это не «вайбкодинг», а настоящий прорыв в скорости. Автор же машет шашкой про «40к строк игры и документации» — это анекдотические примеры, а не анализ.
Итоговая яростная резолюция
Статья — образец инженерного консерватизма, переходящего в отрицание реальности. Автор смешивает три разных явления:
Хайп и дурацкие стартапы (критиковать их можно и нужно)
Реальное улучшение интерфейсов (естественный язык вместо API — это революция, как GUI вместо командной строки)
Свою личную неспособность адаптироваться
Главная ошибка автора: он измеряет LLM по тому, могут ли они заменить его, эксперта, на его же сложной задаче. Не могут — и слава богу. Но они уже заменили десятки тысяч джуниоров, аналитиков, контент-менеджеров, переводчиков. Не потому что «хайп», а потому что задачи этих людей были рутинными и формализуемыми.
Автор предлагает «лучше разбираться в том, что делаешь». Спорить глупо. Но разбираться в том числе означает: понять, где LLM реально сильны, перестать ныть и начать использовать. А пока он пишет саркастичные посты на Хабр, его более молодые и гибкие коллеги уже делают в 3 раза больше за то же время.
Здравый смысл в статье был только один: «не доверяйте слепо продавцам лопат». С этим не поспорить. Реклама повсюду. Кто-то ещё верит, в то, что «Блендамет отбелит ваши зубы»? Но это отменяет факта, что чистить зубы необходимо.
В целом, личное резюме. Статья — унылый скепсис, который через 2–3 года будет выглядеть так же глупо, как статьи 90-х «Зачем вам интернет, есть же библиотеки и энциклопедии».
Но сути не меняет. Автор берёт (видимо, имеет в виду) одну крохотную часть от AI, ещё более крохотную от всего технического процесса в целом, и пытается доказать, что якобы вот конкретно эта часть - не помогает создать ценность, неэффективна.
Парадокс в том, что в качестве доказательства, что "это и раньше было легко", автор приводит пример использования механизма поиска.
При этом он не в курсе, что алгоритмы постоянно улучшаются, в том числе с использованием AI. Автор продолжает пользоваться "поиском", даже не зная о том, что "под капотом" использует AI, а алгоритмы поиска будет продолжать улучшаться, экономя автору время
И так везде - автодополнение в IDE-шках тоже давным давно предлагает список методов не по алфавиту, а "предложка" в виде наиболее подходящих - крохотная AI "под капотом", снова AI давным давно экономит автору время. И вот - её просто усилили в виде AI
Агентная разработка - так ещё больше движухи забирает на себя, экономя разработчикам время
В общем и целом, использование AI в разработке - достаточно очевидно, что экономит разработчикам время, добавочная ценность - налицо. Странно это отрицать.
Да, менеджеры это быстро понимают и, как водится, вместо того, чтобы добавить зарплату за большую сделанную работу, или "отпустить домой" автора - они скорее его уволят, оставив только тех, кто умеет пользоваться новым инструментом.
Быть может, автор и статью с помощью AI написал, но так как инструментом нужно уметь пользоваться - у него не получилось, отсюда столько противоречащих здравому смыслу выводов в ней?
Что по мне - самая большая БЕДА в том, что заполнять базу знаний заставляют разработчика. И беда это не столько разработчика - а в том, что его заставляют писать. Но он не пишет. Или пишет минимум, формально.
Как будто мало других заинтересованных людей, в том, чтобы база заполнялась.
Из статьи абсолютно непонятно, что хотел сказать автор. Возможно, нужно ознакомиться с продуктом? Зашёл на сайт, который автор рекламирует в последней строке.
Итог
Не работают менюхи вверху страницы, ссылка “открыть в браузере” ведёт на https://nooklyru.github.io/nookly-release/ - показывает белый лист.
По тексту на сайте непонятно, что делает программа, и чем она отличается от обсидиана, к которому стотыщ плагинов есть
и, таки, о чём статья?
Спасибо за интересный разбор. Проблема существует, и очень серьёзна, но, как мне видится, она никак не в юридическом поле.
Имеем: некий технологический инструментарий, который эффективен, но даже в теории не может быть безошибочным - поэтому результат требует проверки человеком
Ситуация: человек использовал упомянутый инструментарий, недостаточно проверил результат и допустил поломку
Имеются серьёзные организационные проблемы:
Инструмент реально эффективен, потому к его удачам люди привыкают и начинают всё чаще доверять ему
В следствие появившегося доверия перестраиваются и бизнес-процессы в компании, и вот исполнитель, который раньше подготавливал 1 договор в день, теперь подготавливает их 10, соответственно, он физически не имеет возможости столь тщательно проверять документы, как и раньше
Особенность языковых моделей в том, что, в отличие от людей, умело "маскируют" свои ошибки, под правдоподобные рассуждения. По-другому и быть не может - в этом суть явления конфабуляций ("галлюцинаций"), и ошибку ещё сложнее заметить.
Все эти явления - особенности применения инструмента. После первой эйфории от работы с ним необходимо придумывать правила, которые сведут ошибки к минимуму.
С другой стороны - люди тоже не застрахованы от ошибок, допускают и серьёзные, просто в статье рассматриваются ошибки определённого рода - после использования ИИ, как инструмента.
Бизнес всегда строится с учётом того, что кто-то где-то ошибётся, и подстилается максимум "соломки" под каждый случай.
Таким образом, собственнику бизнеса нужно лишь оценить, где в результате будет больше ошибок - с использованием инструмента, или без него? Сюда же выгоду от его использования, быть может, экономия покроет все расходы на устранения последствий.
А вот юридически всё так, как и сто лет назад.
Во-первых, "виновата" компания. во-вторых, ответственные лица в ней, в третьих - копают дальше, и когда упираются в инструмент, который не является субъектом права - начинают раскручивать в обратную сторону: а кто инструмент устанавливал, кто настраивал, кто обслуживал, кто использовал, какими инструкциями руководствовались, кто писал инструкции и т.д. и т.п.
Я, пожалуй, не добавил к статье ничего нового, кроме того, что все эти рассуждения столетиями применяются к любому инструменту, будь то топор или токарный станок, или станок с ЧПУ, авиалайнер или "ИИ". Юридическая цепочка та же самая.
Идея с чатом для каждой задачи - хорошая, если не сказать - отличная! Так же внедрял в своей системе. :))) Фишка в том, что сообщения - это не только и не столько форма общения, а это ещё и некий "лог выполнения" задачи.
Однако, есть важные нюансы. Если их не учесть,то этот лог выполнения дорого обойдётся.
Прежде чем дать чатик в руки исполнителям - нужно НАУЧИТЬ их культуре написания чата. Учить должна сразу сама система. Писать только нужные сообщения. Писать для читателей, а не просто потому, что захотелось куда-то облегчиться.
А что мы видим на главной страницы YouJile, (копипаста скриншотов которых в статье)?
Зачем мне эти сообщения, как их потребителю. Сижу я, в мыле или в "потоке", точнее, просто РАБОТАЮ, и тут прилетает....
Какие мысли возникнут у человека, который реально работает, а не занимается болтологией, при их прочтении....
"Привет, планирую сегодня доделать макеты главной и страницы контактов"
Зачем мне информация о том, что ты там планируешь? Кого она вообще интересует? У тебя поставлена задача, ну так распланируй её сам, и сделай, когда тебе удобно. Мне зачем эта информация?
"Хорошо. Клиент просит сделать минималистичный сайт в синих тонах ......"
Что это? Дополнения к поставленной задаче? Почему они не были загружены ранее, почему их дописали в ответ на пустое сообщение? А если бы исполнитель просто сделал задачу, не крича об этом на всех коллег, - он бы не получил эти дополнения? Что за культура такая у нас в команде?
"Первые макеты готовы, можно показать"
Что это, кому это? Мне? А где ссылка на макет, или мне звонить нужно куда-то? Тогда где телефон? Если закрыта подзадача - то почему это не автоматическое сообщение, на которое не нужно отвечать а нужно кликать?
"Спасибо, пошёл тестировать"
Кто, зачем и куда пошёл? Зачем эта информация? Понимаю, если запостят
Итого. Сообщения в задаче "Потестировать макеты на целевой аудитории" должны выглядеть примерно так (ориентир для дат возьму со скрина).
3 авг. 11:10 Иван Петров: Первая версия макета готова http://xxx.yyy.ccc/tests1
вообще говоря, это всё, но если развивать идею "важных сообщений", то должно быть как-то так...
4 авг. 10:30 Я: Не хватает кнопки "выбрать все" - выяснили, что заказов бывает слишком много, и кликать каждый утомительно, подробнее тут <Задача>
4 авг. 12:10 Иван Петров: Кнопка добавлена http://xxx.yyy.ccc/tests2
А ещё момент, на скрине у вас чат для задачи "разработать макет", а по факту, в нём написан про старт задачи "Потестировать макеты". Это так и задумано? Чаты не связаны между собой?
Интересная штука получилась. Начал с того, что, ничего не зная об архитектуре мессенджеров - начал расставлять кубики, по своему разумению. После этого упражнения текстовые описания писать гораздо веселее.
Но постоянно возникают вопросы. Что конкретно на каждом этапе выбрано, и ПОЧЕМУ? Какие есть альтернативы, какие критерии выбора, и почему выбрано именно предлагаемое решение.
Ну и ещё момент, вопросы к каждому пройденному этапу - в 100% случаев правильный тот, что содержит самый длинный текст. А ведь тоже хотелось поразмышлять, как и над кубиками.
Очень заинтересовал ваш пост, проект, полез на сайт, и... минут десять пытался понять, что же предложит софт, какова же его эффективность, ну хотя бы на искусственном примере было/стало. В идеале - фото реальных объектов.
Но... к сожалению, ничего не понял, особенно на первой гифке - там вовсе стихийная тропа (коричневым цветом) в самом низу ведёт куда-то вникуда, и явно обе планируемые тропы туда не ведут вовсе
Остальные фото тоже не дали понимания. Возможно, для того, кто в предлагаемом софте уже поработал - всё это будет понятным, но ему и ценность его вряд ли объяснять нужно....
Возможно, если потыркаться и создать демо-проект (я пробовал, но сайт повис, или с сетью проблемы), что-то и прояснится, но,
- во-первых, для этого нужно быть сильно замотивированным, к тому же, видимо, нужно быть архитектором/дизайнером, которые вряд ли относятся к ЛПР (лицам, принимающим решения)
- во-вторых, в софте тоже не будет ярких, чётких, понятных доказательств, что проложенные маршруты работают и приносят пользу.
Таким образом, даже при наличии мотивированного сотрудника в штате - бремя доказательства качества и важности сервиса, целесообразности покупки ложится на него, беднягу сотрудника.
Если у него не получится (а скорее всего нет) - то чиновник или руководитель просто пошлёт его на три буквы, зачем тратить лишних 50К.....
Благодаря наличию гаджетов
я всегда знаю, который час. Потому что мало того, что хорошие внутренние часы - периодически "на автомате" поглядываю на них, и если меня внезапно спросить, то я не подглядывая, скажу время с точностью до двух-пяти минут
всегда владею максимумом контекста информации, не сравнить с бумажным блокнотом, перед любым разговором достаточно проглядеть соответствующий раздел в той же Obsidian, чтобы подготовиться максимально (если это таск‑трекер, и там этот контекст уже есть - ещё проще), это позволяет не потерять нить разговора и выстроить его максимально эффективно
ключи и смартфон - единственные главные две вещи, которые нужно не забыть при выходе из квартиры, именно благодаря тому, что в смартфоне есть всё необходимое (начиная от блокнота, книг, и заканчивая банковскими картами) - я никогда не забываю ключи, в отличие от "аналогового" века, где приходилось тщательно проверять, а всё ли я собрал, и ключи могли потеряться
гаджеты позволили распределить работу именно так, как я хочу, и мало того, что работать не строго по режиму "с 8 до 17", а работать в промежутках, в транспорте, очередях и тому подобных социальных моментах, я знаю, что существует много людей, которые любят дисциплину и порядок, лично меня принудительный приход на рабочее место всегда демотивировал. Если я (пусть даже во внутреннем убеждении) работаю тогда и только тогда, когда захотел - то у меня и мотивация на порядок выше. Тем более, если я использую скучное время типа очереди или в транспорте.
Присутствует некая клиповость мышления, но это абсолютно верный выработанный механизм: ведь благодаря гаджетам и, как следствие, наличию моментального доступа к информации - количество этой информации, одновременно используемых сфер деятельности, настолько велико, что если в глубину, "на полный штык" копать хотя бы половину из них - на это уйдут десятилетия и работа встанет.
Поменялись шаблоны поведения. Деды избу одним топором ставили. Сейчас иной строитель топором пользоваться вовсе не умеет. Деменция ли это?
Не совсем понятно, в чём проблема. Разве "сужать пространство вариантов" - не задача руководителя? Ну как минимум организовать этот процесс. Но закопать голову в песок и молчать о проблемах - вряд ли лучшее решение для этого.
В команде как воздух нужны все типы личности, в том числе, параноики, иначе действительно можно упустить что-то важное.
Если чётко определить, что делать со всеми самыми страшными предположениями - например, (молча) фиксировать их, после чего
- ранжировать по возможным рискам
- прописать планы/протоколы действий, в случае возникновения
- после старта провести ретроспективу, правильно ли были оценены риски
А тем более - привлечь к этому процессу ту самую Женю, а то и назначить ответственным
То не только проблемы не возникнет - можно и нужно получить значительный профит от роли адвоката дьявола: ведь если хотя бы иногда предсказания сбываются, так почему бы не быть к ним готовыми?
Круто! Серьёзная работа.
Серьёзно смущает один момент.
Разработчику не нужно глубоко погружаться в предметную область - это вредно: он может забыть про то, как нужно делать. А что нужно делать - решает аналитик, который, как раз, в предметную область погружён максимально. Это настолько разные специальности, что их одновременное выполнение чревато неким раздвоением личности: это из личного опыта, т.к. приходилось совмещать. И в своей команде я разделил эти роли.
.
К сожалению, на предприятиях "далёких" от IT, понимание важности качественной проработки требований, как правило, отстутствует. Сам работаю на машиностроительном предприятии, и на 300+ разработчиков ровно 0 аналитиков. Нет такой специальности.
Парадоксально, но в ВУЗах, с которыми плотно сотрудничаем, есть цельные кафедры, подготавливаются специалисты. А на заводе даже вакансии такой нет.
Руководство считает, что это мелочи, "у нас каждый программист - аналитик"(с)
Как дело обстоит у вас? Есть ли отдельные специалисты по анализу и подготовке требований? (а так же планированием разработки, их последующей корректировке, тестировании, UI/UX исследований и т.д., чем и должен заниматься аналитик)
Есть такое понятие, "коллективное владение кодом". Оно в команде обязано быть в наличии!
НО если этот самый код (блок кода, модуль, имплементацию) - пишет один человек, а остальные молятся на него, то с какого перепуга этого работягу заставлять писать ещё и документацию?
Пусть тогда остальные тоже потрудятся: хотя бы попытаются этот код понять и задокументировать его.
Задокументировать, именно так, как они его поняли - а трудяга, прочитав этот документ, поймёт, поняли его, или не поняли, и что поняли не так.
Пара-тройка итераций - и вот и документация готова и понимание появилось. Без какого-либо взаимодействия и трат времени трудяги на разъяснения и тем более на разработку документов - пусть продолжает писать только код.
Сто раз так практиковал - неимоверная эффективность детектед.
Иначе несправедливо получается: работает один, а потом ещё и репетитором, да ещё в письменном виде - книги документов пишет. А остальные на расслабончике проехались, "не понятно им, разъясните, научите".
всё-таки, возвращаясь к теме использования LLM
С "одного промпта" вообще редко что-то дельное выйдет, если только вопрос не тривиален, а ответ на него и в гугле можно получить.
Нужно понимать "сущность" LLM - они и "обрадовать" просителя хотят, и контекст у них крохотный, а ещё есть такая штука, как "внимание" модели.
Даже задачи "средней" сложности лучше решать в разных "слоях". На примере создания комментария: ну как минимум сначала запросить выделить ключевые темы, чтобы убедиться, что они все там (и, обратно, что ты ничего не упустил) - потом вычищение мусора (например, у меня непрошенные хвалебные оды появились), потом чёткие формулировки, чего хочешь ты - (например, у меня объективной критики, по существу, со стройной логической аргументацией)
ахахаха, а это результат последней правки "добавь эмоций, жесткости и юмора": это не LLM "ошиблась", это я забыл, куда отправляю текст
по дефолту "градус" был гораздо ниже - модели заботятся о ранимых
я думаю, если бы заморочился, и попросил бы её проанализировать хабр и выдать в стиле, чтобы получить плюсы - то и результат бы не "-18", а "+18" получился бы, но такой стиль не нравится лично мне.
и тут - либо шашечки, либо ехать.
В любом случае, подавляющее большинство критики моделей и "вайбкодинга", которое встречается не только здесь, но и вообще в интернете, как правило, основывается на гипотезах, что всё должно получиться "с одного промпта", возможно, авторы пытались писать такие чудо-промпты, вместо того, чтобы выстраивать методологию, я уж не говорю об агентских сетях
Их посты напоминают страх, как в древности, когда станки заменяли ремесленников, и те, справедливо, пытались доказать, что ремеслом они делают гораздо более качественные вещи (и так оно и было), но прогресс в результате взлетает не от отдельных станков, а от системы: пусть на каждом этапе есть огрехи, и отдельно взятый Левша подкуёт блоху гораздо круче, но в сумме результат работы "сетей" станков даёт результат разительно большей эффективности и качества.
Уверен, с разработкой будет то же самое. Ручное написание кода на языках высокого уровня станет рудиментом, в основной своей массе: останется только в ключевых местах.
Как это произошло, когда ремесленников заменили бездушными станками.
Как это произошло с тем же ассемблером.
Меня заминусовали настолько, что отвечать могу раз в сутки.
Однако, по существу всего три поста, могу ответить на один. Постараюсь на все разом. Давайте по пунктам
обратите внимание на множество ответов по посту, созданного с использованием LLM: претензии в основном только потому что "использовал" - кошмар кошмарный
Но.. да, конечно использовал так: моя цель была как раз показательно показать:)), что LLM, именно языковая модель экономит время и улучшает качество кода, как программного, так и текст комментария.
Я не сомневаюсь, что кто-то "из головы" пишет такой код, что рефакторинг не нужен, как и то, что тексты статей тоже "из головы" напрямую пишут такие, что редактура не нужна.
Но, как показывает практика, что в работе над программным кодом, что в комментариях к статье - "красивый" код это либо в чьих-то фантазиях, либо напоказ. В продакшен (комментарии) идёт код так себе, "лишь бы работал".
Потому и "узнали", что использовалась LLM: качество текста комментария выбивается - обычно в комментариях никто особо над качеством не думает, пишут, порой даже на абзацы не разбив.
Качество было слишком хорошее для комментария, а больше претензий к тому посту, по сути и не было.
Обратите внимание, критики высказывают гипотезу, якобы я промпт написал, а оно всё сгенерило за меня. Но она в корне не верна.
Типичная ошибка работы с языковыми моделями. Кто так работает "с одного промпта" - они и разочаровываются. А после разочарования - LLM во всём обвиняют.
Так и здесь: якобы LLM раскритиковала статью (а я типа тут ни при чём, не прочитал и выложил).
Как на деле: промптов было несколько. К слову, в первой версии, где я просил обозначить ключевые моменты (чтобы не забыть про них) - модель вообще без спросу расхвалила статью и подкрепила собственными примерами, как всё круто сказано.
То есть, на деле было всё наоборот: я выдавал инструкции, что хочу получить, в каком виде, в каком стиле, до тех пор, пока не получил требуемый результат.
Но такому поведению нужно научиться, к нему нужно привыкнуть
При работе с программным кодом были проблемы: поначалу сложно было "себя сломать", чтобы не править за LLM-кой, а именно промптами корректировать результат. С трудом, но научиться удалось. Это ещё до агентской разразботки, сейчас это на другом уровне.
Впрочем, с критикой, подобной вчерашней, я сталкивался и 15 лет назад, сталкивается с подобным, наверное любой руководитель: когда ты проходишь этапы:
- начинающему кодеру объясняешь задачу, корректируешь работу, которую ему поручил, и злишься про себя, что ты бы это уже давно сам написал за 15 минут, а убил уже лично 3 часа
- через какое-то время (месяцы) происходит профит, и вот кодер уже "вышел в ноль", и теперь уже затраты окупаются, 15 минут убил, 15 - выиграл
- через какое-то время уже объяснять ничего не нужно - он пишет сам, замечательно, в "твоём стиле", но сам. И ведь обязательно найдутся люди, которые скажут, что мол - вот Вася всё делает, молодец, а начальник вообще зачем тут нужен
Так и с этой статьёй - статья написана, LLM то ли молодец, то ли наоборот, плохая (непонятно в чём), а автор поста - вовсе не автор, а рядом проходил.
Ответ на ваш вопрос, "Вы кстати разработчик, прям пишите код?" не просто сам пишу, а в буквальном смысле заставляю всех, кто ещё "не допёр" - использовать LLM-ки. Если они ещё не понимают смысла, не умеют с ними работать - значит, нужно учить!
Не увольнять "джунов" нужно, а учить пользоваться современными инструментами для разработки.
"Как правило специалисты хорошо знают тот инструмент что используют, например язык, фреймворк, библиотеку" - ну, это к пункту 1.
Для меня дело обстоит с точностью до наоборот: как раз если я хорошо знаю язык, фреймворк, с которым работают - то непременно обращусь к "нейронке", потому что я смогу оценить результат буквально с одного взгляда, при правильной настройке она вообще напишет за секунды то, что я бы набирал бы в десять раз дольше.
При этом она может учесть то, что я мог банально забыть. Именно в сценарии, когда инструментарий знакомый и задача предельно ясна нейронки и дают максимальный прирост скорости, чаще "с первого промпта".
Это на замудрёных задачах, когда сам "не можешь понять, чего хочешь, пока не начнёшь кодить" - они не дают значимого результата "с первого промпта".
А кто сказал, что не бежали скупать индусов?
Валом скупали!
Знакомый работал архитектором в одном зарубежном банке - уволился потому, что тяжко работать было с индусами, мало того, что увидел воочию, что "идусский код" - это не миф, мало того, что те английского почти не знают, так ещё и меняли их, как перчатки: только с одним коммуникацию наладишь - рраз, а перед тобой уже другой.
львиную долю кода в банке писали индусы, штат был раздут неимоверно, только архитектору-перфекционисту не нравилось всё это
реальный бизнес - это не всегда про "хороший код"
а архитектуру тот же клауд коде в огромном числе случае нарисует лучше, чем средней руки кожаный разработчик, а профессионалов и звёзд среди них - ты найди ещё попробуй
Вы не представляете сколько лично я "шишек" набил ещё на заре становления LLM-ок, да вот классика, с автодополнением, когда один "бот" вставлял косячный код, я, разобравшись - снёс его, написав всё правильно руками
а потом выяснилось, что я где-то в промежутке автоматом нажал ctrl+S (никак не могу избавиться от привычки) и другой бот, который годами мне только помогал, вставил "левые" библиотеки аккурат для говнокода от автодополнения
в подключенных либах у пары функций сигнатуры пересекались, и ошибка эта вылезла "боком" только через несколько дней - и искал я её несколько часов....
постепенно выработались и правила работы и "техника безопасности" в общении с моделями
оно и понятно - если не уметь пользоваться инструментом, то можно и пальцы себе отпилить, но это не повод отказываться от бензо/электро пилы в угоду ручной ножовке, только потому, что те опасны
P.S. в своё время был впечатлён статьёй "90% кода в интернете - говно"
https://www.gunsmoker.ru/2010/05/90.html
Понравились не выводы автора - он Америку не открыл, и ни в коем случае не говорил о том, какие "вредные ресурсы" а-ля stackoverflow, он дал конкретный рецепт, технику безопасности, как их использовать, и я эту статью всем своим и знакомым начинающим разработчикам рассылал - чтобы поняли, как использовать и стековерфлоу, и профильные форумы
а не возмущались, когда, скопипастив чужой код, получали ещё больше проблем, чем было до
Всё мимо и мимо
Да нет же, LLM как раз не ошибается в подобных мелочах: на тот момент два ваших ответа, конкретно под моим постом (ниже, по цепочке), конкретно про меня, как это чётко, правильно без ошибок назвать - с этим справится LLM, но на них лень переключаться, самому подбирать слова - долго, оставил, как есть. Да, я так пишу.
Вас это уже раздражает, вы возмущены.
Но, простите, у меня нет времени колдовать над каждым словом, я не книгу пишу.
Во-вторых, чем не понравился мой пост? Отсутствием подобных формальных ошибок? Не к чему прицепиться? Да, беда бедовая! Остаётся только навешать ярлык "разговариваю с LLM", и добавить "это ниже моего достоинства".
Предположим, я LLM
От кожаного zum уже два коммента в ответ мне.
В них - только ярлыки, никакого конструктива.
Вы всё ещё против прогресса? :)))
Буду бить сразу "классикой". Клиффорд Столл
https://1995blog.com/2018/02/28/re-reading-clifford-stolls-1995-internet-predictions-bah/
А низкопробного качества контента на эту тему было... тысячиих.
Сложно на столь длинный выпад ответить коротко, слишком много навайбкодил автор. Давайте поправим ситуацию, заодно немного структурировав выводы в статье.
Вот яростная, но аргументированная критика статьи. Автор получит по полной — за высокомерие, логические дыры и неспособность увидеть изменения, которые уже произошли.
Суть статьи (глазами критика)
Автор — типичный «олдскульный» программист, который отчаялся чувствовать себя особенным. Он пишет желчную отповедь, чтобы убедить себя и других: «ничего не поменялось, я по-прежнему незаменим». Его главный тезис — LLM всего лишь дешёвый аналог Google и конструкторов сайтов. Это наглая ложь, подкреплённая подборкой удобных примеров и игнорированием того, что не вписывается в его картину мира.
Пять идей — и почему они не выдерживают критики
1. «Доступность инструментов была и до LLM»
Автор заявляет: «pandas читает Excel одной строчкой, CMS делают сайты — ничего нового». Это интеллектуальное мошенничество через подмену понятий.
Раньше вы должны были знать, что именно написать:
df.agg(["sum", "min"]). А теперь вы говорите: «посчитай сумму и минимум по колонкам» — и LLM сама пишет этот код, даже если вы никогда не слышали о pandas.Вы не понимаете разницы между инструментом для профессионала (pandas, CMS) и интерфейсом для непрофессионала (естественный язык). LLM убрали барьер входа не «чуть-чуть», а полностью. Спросите любого менеджера, который вчера собрал парсер без единой строки кода — он вам объяснит, что Google ему не помог бы.
И да, раньше не было возможности одной фразой «сделай как в том репозитории, но поменяй цвет кнопки на красный и добавь валидацию email» получить рабочий код. Не было. Автор врет.
2. «Спецификация сложнее кода» — главная глупость статьи
Автор с гордостью неофита заявляет, что «написать детальное описание на естественном языке сложнее, чем сразу код». Это чушь, которую повторяют только те, кто никогда не писал сложную спецификацию.
В реальной разработке спецификация всё равно нужна — хоть на русском, хоть в виде тикетов, хоть в виде тестов. LLM позволяет превратить спецификацию в код мгновенно, а не тратить часы на синтаксис, отладку угловых скобок и поиск того самого
;.Сравните: «авторизация через JWT, время жизни 15 минут, рефреш в httpOnly cookie» — это 15 слов. Написать это на Go или даже Python с обработкой ошибок — 50+ строк. Что проще? Очевидно.
Автор путает сложность промпта для неясной задачи (когда вы сами не знаете, что хотите) со сложностью промпта для понятной задачи. Если задача понятна, промпт в 10 раз короче кода. Если задача не понятна — никакой код вам не поможет, вы будете переписывать его 20 раз. LLM тут вообще не при чем.
3. «Хайп навязывается, а эффективность не измеряется»
Автор возмущается, что нет метрик, кроме подсчёта токенов. А давайте спросим: а раньше была метрика эффективности использования Google? Или Stack Overflow? Нет. Но почему-то никто не называл это «хайпом».
То, что автор называет «принуждением» — это естественная реакция бизнеса на 10-кратное ускорение прототипирования. Если бы он работал в компании, где скорость выхода MVP решает всё, он бы не ныл про «аггрессивную рекламу».
Отсутствие метрик — проблема менеджмента, а не технологии. Но автор предпочитает бить по LLM, а не признать, что его компания не умеет измерять производительность в принципе.
И главное: пользователи сами выбирают ИИ-инструменты. Github Copilot платный, но им пользуются миллионы. Не потому что «менеджеры заставили», а потому что он реально экономит время. Автор, видимо, не пробовал.
4. «Генерация не создаёт ценности, только спам»
Здесь автор окончательно срывается в склероз и снобизм.
«Люди не хотели написать книгу — а теперь сгенерировали». А с чего вы взяли, что они не хотели? Может, у человека есть идея, но нет навыка выстроить 300 страниц прозы. LLM даёт инструмент реализации. И да, появляется больше книг — и среди них есть хорошие. Так же как появление дешёвых камер не убило фотографию, а породило миллионы новых фотографов.
Пример с Пелевиным — логическая уловка. Автор берёт вершину литературного мастерства и доказывает, что её нельзя сгенерировать. А никто и не говорит, что можно. Но можно сгенерировать 90% прикладного контента: документацию, ответы в поддержку, черновики писем, SQL-запросы, bash-скрипты, конфиги. Это огромная ценность.
«Никакой новой ценности не создаётся» — ах вот как? А автоматическая расшифровка аудиозаписей? А перевод видео в реальном времени? А генерация тестовых данных для БД? А рефакторинг легаси с сохранением поведения? Всё это появилось именно благодаря LLM. Автор просто не знает, куда смотреть.
5. «Профессионалы уже эффективны, LLM не помогают»
Самое оскорбительное и недалёкое утверждение. Автор говорит от лица «настоящих профессионалов», но на самом деле — от лица застоя.
Опытный разработчик с 10+ лет стажа тратит часы на рутину: написать однотипные CRUD-контроллеры, покрыть их тестами, поправить импорты, переименовать переменные. LLM делает это за 5 секунд. Профессионал становится в 5–10 раз быстрее на скучных задачах — и может сфокусироваться на архитектуре. Это называется рост эффективности, а не «почти не помогает».
Автор пишет: «они умеют гуглить». Гуглить — значит читать документацию, находить пример, адаптировать под свой контекст. LLM даёт готовый адаптированный ответ за 2 секунды. Разница в затраченном времени — два порядка.
И последнее: сам автор статьи явно не пробовал современные LLM в серьёзной работе. Потому что любой, кто реально использовал Cursor или Copilot с контекстом проекта, знает: это не «вайбкодинг», а настоящий прорыв в скорости. Автор же машет шашкой про «40к строк игры и документации» — это анекдотические примеры, а не анализ.
Итоговая яростная резолюция
Статья — образец инженерного консерватизма, переходящего в отрицание реальности. Автор смешивает три разных явления:
Хайп и дурацкие стартапы (критиковать их можно и нужно)
Реальное улучшение интерфейсов (естественный язык вместо API — это революция, как GUI вместо командной строки)
Свою личную неспособность адаптироваться
Главная ошибка автора: он измеряет LLM по тому, могут ли они заменить его, эксперта, на его же сложной задаче. Не могут — и слава богу. Но они уже заменили десятки тысяч джуниоров, аналитиков, контент-менеджеров, переводчиков. Не потому что «хайп», а потому что задачи этих людей были рутинными и формализуемыми.
Автор предлагает «лучше разбираться в том, что делаешь». Спорить глупо. Но разбираться в том числе означает: понять, где LLM реально сильны, перестать ныть и начать использовать. А пока он пишет саркастичные посты на Хабр, его более молодые и гибкие коллеги уже делают в 3 раза больше за то же время.
Здравый смысл в статье был только один: «не доверяйте слепо продавцам лопат». С этим не поспорить. Реклама повсюду. Кто-то ещё верит, в то, что «Блендамет отбелит ваши зубы»? Но это отменяет факта, что чистить зубы необходимо.
В целом, личное резюме. Статья — унылый скепсис, который через 2–3 года будет выглядеть так же глупо, как статьи 90-х «Зачем вам интернет, есть же библиотеки и энциклопедии».
Так это и есть AI. Вы определение почитайте....;)
Но сути не меняет. Автор берёт (видимо, имеет в виду) одну крохотную часть от AI, ещё более крохотную от всего технического процесса в целом, и пытается доказать, что якобы вот конкретно эта часть - не помогает создать ценность, неэффективна.
Ну да, прогресс в целом не приносит ценности.
В этом и страх, и гимн луддитов.
Парадокс в том, что в качестве доказательства, что "это и раньше было легко", автор приводит пример использования механизма поиска.
При этом он не в курсе, что алгоритмы постоянно улучшаются, в том числе с использованием AI. Автор продолжает пользоваться "поиском", даже не зная о том, что "под капотом" использует AI, а алгоритмы поиска будет продолжать улучшаться, экономя автору время
И так везде - автодополнение в IDE-шках тоже давным давно предлагает список методов не по алфавиту, а "предложка" в виде наиболее подходящих - крохотная AI "под капотом", снова AI давным давно экономит автору время. И вот - её просто усилили в виде AI
Агентная разработка - так ещё больше движухи забирает на себя, экономя разработчикам время
В общем и целом, использование AI в разработке - достаточно очевидно, что экономит разработчикам время, добавочная ценность - налицо. Странно это отрицать.
Да, менеджеры это быстро понимают и, как водится, вместо того, чтобы добавить зарплату за большую сделанную работу, или "отпустить домой" автора - они скорее его уволят, оставив только тех, кто умеет пользоваться новым инструментом.
Быть может, автор и статью с помощью AI написал, но так как инструментом нужно уметь пользоваться - у него не получилось, отсюда столько противоречащих здравому смыслу выводов в ней?
Что по мне - самая большая БЕДА в том, что заполнять базу знаний заставляют разработчика.
И беда это не столько разработчика - а в том, что его заставляют писать. Но он не пишет. Или пишет минимум, формально.
Как будто мало других заинтересованных людей, в том, чтобы база заполнялась.