Очень заинтересовал ваш пост, проект, полез на сайт, и... минут десять пытался понять, что же предложит софт, какова же его эффективность, ну хотя бы на искусственном примере было/стало. В идеале - фото реальных объектов.
Но... к сожалению, ничего не понял, особенно на первой гифке - там вовсе стихийная тропа (коричневым цветом) в самом низу ведёт куда-то вникуда, и явно обе планируемые тропы туда не ведут вовсе
Остальные фото тоже не дали понимания. Возможно, для того, кто в предлагаемом софте уже поработал - всё это будет понятным, но ему и ценность его вряд ли объяснять нужно....
Возможно, если потыркаться и создать демо-проект (я пробовал, но сайт повис, или с сетью проблемы), что-то и прояснится, но,
- во-первых, для этого нужно быть сильно замотивированным, к тому же, видимо, нужно быть архитектором/дизайнером, которые вряд ли относятся к ЛПР (лицам, принимающим решения)
- во-вторых, в софте тоже не будет ярких, чётких, понятных доказательств, что проложенные маршруты работают и приносят пользу.
Таким образом, даже при наличии мотивированного сотрудника в штате - бремя доказательства качества и важности сервиса, целесообразности покупки ложится на него, беднягу сотрудника.
Если у него не получится (а скорее всего нет) - то чиновник или руководитель просто пошлёт его на три буквы, зачем тратить лишних 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 написал, но так как инструментом нужно уметь пользоваться - у него не получилось, отсюда столько противоречащих здравому смыслу выводов в ней?
Что по мне - самая большая БЕДА в том, что заполнять базу знаний заставляют разработчика. И беда это не столько разработчика - а в том, что его заставляют писать. Но он не пишет. Или пишет минимум, формально.
Как будто мало других заинтересованных людей, в том, чтобы база заполнялась.
Но по крайней мере в Туапсе - для большинства из таких вот Кабанчиков уже случилась задница. Пришли большие, мощные и более современные сети. Издержки меньше, цены ниже, обороты большие. И можно себе много чего позволить. И уже куча эти самых мелких магазинчиков у дома - позакрывались.
А многие из таких вот Кабанчиков - оказались без рабов, прибылей. И сами по итогу вышли за забор. И сейчас - они сами и их жены оказываются вынуждены уже самостоятельно идти и работать на Магниты и Пятерочки :)
Все дело в том что Кабанчики - это не предприниматели а схемщики. И все что схемщикам сейчас остается (если они не будут перестраиваться, а они этого в большинстве своем делать не хотят) - доживать и дожимать что ещё смогут. Но большие и крупные сети их уже дико душат. Озон и WB - тоже нанесли серьёзный удар по подобным Кабанчикам
Вот так вывод!
Простите, но на каком основании возникло допущение, будто "более современные сети" выдают лучшие условия для сотрудников?
Из практики - именно в крупных сетях и "уничижают" работников, и устраивают их как "самозанятых", без корректного трудового договора, дабы все соки вытянуть и выкинуть. Работники бесправны в большинстве своём - и это известная проблема.
Что касательно арифмктики - тот же Ozon вообще убыточен, до сих пор в долгах и в плюс не вышел.
"Ламповые" мелкие бизнесы они задушили, да. Но по отношению к сотрудникам, к их условиям работы (о чём исходная статья) - там ли лучше?
Стул чинит плотник Унитаз течёт - сатехник Лампочку меняет электрик Кондиционер чинит вообще отдельная служба Локальная сеть, интернет - IT, безопасники Да я даже винду себе на комп не сам ставил, и лет дцать как забыл, как это делается.
Сейчас всё намного проще - проблемы, описанные в статье, как правило, чинятся банальными заявками, ну... в "худшем" случае - они на аутсорсе, и делов-то остаётся: определить этот крохотный бюджет, и донести его важность для работы руководителю. Ну и взять на себя чуть ответственности, и принять все эти работы.
Немного подтолкнуть - и всё заработает, как маятник у часов.
Проблема в том, что людей, которые способны это сделать - ничтожно мало.
Большинство ограничатся болтовнёй на эту тему в курилке, а по выходу из неё - сядут на ненавистный скрипящий стул и продолжат работу, как ни в чём не бывало.
Спольский описывает свои реалии, где работа масштабируется на миллионов потребителей, а сетевой эффект может окупить любые начальные расходы (и у него таки получилось со Stack Overflow)
Полностью согласен! Однако, и у нас стоимость (аренды) отдельных помещений может быть не столь заоблачна, а его расчёты показывают, что "отвлечения" реально стоят дорого
Но в и у Спольски, и у автора не упоминается тот факт, что не всем вообще отдельный кабинет нужен. Кого-то и скрипучий стул может на рабочий лад настраивать.
У меня есть хороший знакомый, который ушёл в офис на зарплату в три раза меньше, при даже немного большем объёме работ. Основная причина - "не вынес" работу на удалёнке, "не его это".
Привык, когда шум, гам, и сам может в любой момент "рассказать, что сделал" (чем неимоверно бесил некоторых коллег).
Привык, когда он "и сец и жнец и на дуде игрец", поэтому размеренная работа по удалёнке по чётким таскам в джире стало для него пыткой, "почувствовал себя винтиком".
То ли дело - когда отвечаешь за всё, разом, за весь проект и тащишь его в одиночку.
Люди до сих пор в шоке. И там, откуда он уволился, и там, куда пришёл (в офис, на почти что гос.предприятие), точнее, не пришёл - вернулся.
Основная проблема в том, что все проблемы не решить. Не подотрёшь, прошу прощения, каждому мягкое место... У руководителя главная задача - процессы обеспечить, коммуникацию, корректные постановки задач и т.д. - что, к слову, никакого отношения к "рабочему месту" не имеет.
Если совсем заморочиться - я бы в первую очередь поставил во главу угла "офисный гул". Наушники с ANC для меня стали в своё время спасением.
Есть небезызвестная статья от Joel Spolsky, в которой он призывает нанимать в программирование только "звёзд", с их 10х эффективностью и 100х качеством, да ещё выделить каждому отдельный кабинет - и так в сумме будет гораздо дешевле (у него в статье конкретные расчёты, как условного Петю может выбить из мыслительного процесса условный коллега Вася одним простейшим вопросом) - расчёты базируются на высокой зарплате "звезды", потому отдельный кабинет - реальная экономия.
Но реальность всё расставляет на свои места - "звёзд" не набраться, с ними проблемы, равно как и решить абсолютно все мелкие бытовые офисные вопросы. До них нужно ещё добраться, а директор давно в отдельном кабинете в другом быте, и забыл уже, как это было на начале его карьеры.
Он назначил HR (они, наверное, должны отвечать за удобство?) или кто? Но HR тоже не "звезда", и скорее всего зарплата его даже ниже айтишников, и квалификация соответствующая... Не увидит он массовую проблему со стульями, но найдёт в интернете статью про важность корпоратива - и подготовит предложение по улучшению руководству.
А инженеры...Ну не привыкли они общаться с руководством, на хабр проще статью выкатить. Потому массово "жрут кактус".
Даже с девочкой-HR поговорить им сложно.
А делов-то, предложить ввести статью расходов на мелкие улучшения, обосновать экономический эффект, примерно определить бюджет в месяц/год, думаю, это вообще не вопрос будет.
хе... объявить конкурс среди сотрудников на лучшее предложение по улучшению рабочего места и по тому, на что тратить этот самый бюджет - вот тебе игрофикация процесса
оно понятно, идиотов среди руководителей не меньше, чем среди рядовых инженеров, а то и больше: найдутся и такие, кому "чем хуже - тем лучше", но это тема отдельной статьи, потому как такие недоумки эту статью даже открывать не станут
Очень заинтересовал ваш пост, проект, полез на сайт, и... минут десять пытался понять, что же предложит софт, какова же его эффективность, ну хотя бы на искусственном примере было/стало. В идеале - фото реальных объектов.
Но... к сожалению, ничего не понял, особенно на первой гифке - там вовсе стихийная тропа (коричневым цветом) в самом низу ведёт куда-то вникуда, и явно обе планируемые тропы туда не ведут вовсе
Остальные фото тоже не дали понимания. Возможно, для того, кто в предлагаемом софте уже поработал - всё это будет понятным, но ему и ценность его вряд ли объяснять нужно....
Возможно, если потыркаться и создать демо-проект (я пробовал, но сайт повис, или с сетью проблемы), что-то и прояснится, но,
- во-первых, для этого нужно быть сильно замотивированным, к тому же, видимо, нужно быть архитектором/дизайнером, которые вряд ли относятся к ЛПР (лицам, принимающим решения)
- во-вторых, в софте тоже не будет ярких, чётких, понятных доказательств, что проложенные маршруты работают и приносят пользу.
Таким образом, даже при наличии мотивированного сотрудника в штате - бремя доказательства качества и важности сервиса, целесообразности покупки ложится на него, беднягу сотрудника.
Если у него не получится (а скорее всего нет) - то чиновник или руководитель просто пошлёт его на три буквы, зачем тратить лишних 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 написал, но так как инструментом нужно уметь пользоваться - у него не получилось, отсюда столько противоречащих здравому смыслу выводов в ней?
Что по мне - самая большая БЕДА в том, что заполнять базу знаний заставляют разработчика.
И беда это не столько разработчика - а в том, что его заставляют писать. Но он не пишет. Или пишет минимум, формально.
Как будто мало других заинтересованных людей, в том, чтобы база заполнялась.
Вот так вывод!
Простите, но на каком основании возникло допущение, будто "более современные сети" выдают лучшие условия для сотрудников?
Из практики - именно в крупных сетях и "уничижают" работников, и устраивают их как "самозанятых", без корректного трудового договора, дабы все соки вытянуть и выкинуть. Работники бесправны в большинстве своём - и это известная проблема.
Что касательно арифмктики - тот же Ozon вообще убыточен, до сих пор в долгах и в плюс не вышел.
"Ламповые" мелкие бизнесы они задушили, да. Но по отношению к сотрудникам, к их условиям работы (о чём исходная статья) - там ли лучше?
А не получится так. Мир меняется.
Стул чинит плотник
Унитаз течёт - сатехник
Лампочку меняет электрик
Кондиционер чинит вообще отдельная служба
Локальная сеть, интернет - IT, безопасники
Да я даже винду себе на комп не сам ставил, и лет дцать как забыл, как это делается.
Сейчас всё намного проще - проблемы, описанные в статье, как правило, чинятся банальными заявками, ну... в "худшем" случае - они на аутсорсе, и делов-то остаётся: определить этот крохотный бюджет, и донести его важность для работы руководителю. Ну и взять на себя чуть ответственности, и принять все эти работы.
Немного подтолкнуть - и всё заработает, как маятник у часов.
Проблема в том, что людей, которые способны это сделать - ничтожно мало.
Большинство ограничатся болтовнёй на эту тему в курилке, а по выходу из неё - сядут на ненавистный скрипящий стул и продолжат работу, как ни в чём не бывало.
Полностью согласен!
Однако, и у нас стоимость (аренды) отдельных помещений может быть не столь заоблачна, а его расчёты показывают, что "отвлечения" реально стоят дорого
Но в и у Спольски, и у автора не упоминается тот факт, что не всем вообще отдельный кабинет нужен. Кого-то и скрипучий стул может на рабочий лад настраивать.
У меня есть хороший знакомый, который ушёл в офис на зарплату в три раза меньше, при даже немного большем объёме работ. Основная причина - "не вынес" работу на удалёнке, "не его это".
Привык, когда шум, гам, и сам может в любой момент "рассказать, что сделал" (чем неимоверно бесил некоторых коллег).
Привык, когда он "и сец и жнец и на дуде игрец", поэтому размеренная работа по удалёнке по чётким таскам в джире стало для него пыткой, "почувствовал себя винтиком".
То ли дело - когда отвечаешь за всё, разом, за весь проект и тащишь его в одиночку.
Люди до сих пор в шоке. И там, откуда он уволился, и там, куда пришёл (в офис, на почти что гос.предприятие), точнее, не пришёл - вернулся.
Основная проблема в том, что все проблемы не решить.
Не подотрёшь, прошу прощения, каждому мягкое место...
У руководителя главная задача - процессы обеспечить, коммуникацию, корректные постановки задач и т.д. - что, к слову, никакого отношения к "рабочему месту" не имеет.
Если совсем заморочиться - я бы в первую очередь поставил во главу угла "офисный гул". Наушники с ANC для меня стали в своё время спасением.
Есть небезызвестная статья от Joel Spolsky, в которой он призывает нанимать в программирование только "звёзд", с их 10х эффективностью и 100х качеством, да ещё выделить каждому отдельный кабинет - и так в сумме будет гораздо дешевле (у него в статье конкретные расчёты, как условного Петю может выбить из мыслительного процесса условный коллега Вася одним простейшим вопросом) - расчёты базируются на высокой зарплате "звезды", потому отдельный кабинет - реальная экономия.
Но реальность всё расставляет на свои места - "звёзд" не набраться, с ними проблемы, равно как и решить абсолютно все мелкие бытовые офисные вопросы. До них нужно ещё добраться, а директор давно в отдельном кабинете в другом быте, и забыл уже, как это было на начале его карьеры.
Он назначил HR (они, наверное, должны отвечать за удобство?) или кто? Но HR тоже не "звезда", и скорее всего зарплата его даже ниже айтишников, и квалификация соответствующая... Не увидит он массовую проблему со стульями, но найдёт в интернете статью про важность корпоратива - и подготовит предложение по улучшению руководству.
А инженеры... Ну не привыкли они общаться с руководством, на хабр проще статью выкатить. Потому массово "жрут кактус".
Даже с девочкой-HR поговорить им сложно.
А делов-то, предложить ввести статью расходов на мелкие улучшения, обосновать экономический эффект, примерно определить бюджет в месяц/год, думаю, это вообще не вопрос будет.
хе... объявить конкурс среди сотрудников на лучшее предложение по улучшению рабочего места и по тому, на что тратить этот самый бюджет - вот тебе игрофикация процесса
оно понятно, идиотов среди руководителей не меньше, чем среди рядовых инженеров, а то и больше: найдутся и такие, кому "чем хуже - тем лучше", но это тема отдельной статьи, потому как такие недоумки эту статью даже открывать не станут