Comments 129
Сложно поверить что ИИ мердж на 5к строк кода будет контролировать разработчик который сидит за рулем. Проверит тесты, которые тот же ИИ написал и готово.
Но с другой стороны вот пишем мы, на шарпе или на javascript код, ассемблер же никто не проверяет. Скажете что преобразования при компиляции однозначные? Но они не однозначные и систем на которых это исполняется множество. Может агенты которые пишут код и постановки это еще один уровень абстракции и процесс "писать ручками" рано или поздно устареет? Самого это напрягает.
Преобразование высокоуровневого кода в ассемблер / байткод - оно разве non-deterministic? Вводных данных, влияющих на результат много, но так ли прям мы не можем однозначно узнать, что получим на выходе, если все параметры учесть? А с LLMками не так, вон говорят они даже agents.md читают по настроению
Библиотеки мы используем как подключаемые файлы, зная входной и выходной интерфейс и полагаемся на них. Драйвера и железо на ПК разные. А если модуль на входе и на выходе предсказуемый и работает приемлемое время, то "есть ли разница, какого цвета кошка?", написал его человек или нейронка.
Если предсказуемый...
Библиотеки вы ведь не все подряд используете. А проверенные вами в том числе.
А если написать тесты покрывающие ВСЁ, то написать для них "вручную" код займет 1% времени.
Как бы кто не писал тесты - они никогда не покрывают откровенный саботаж. Ну т.е. легко представить себе что нейронка вам напишет внутри функции суммы if a=8546745764 sum=7524675, как будете проверять :) ?
Ловил недавно баг, где агент в цикле начал дергать метод, который сам же благополучно удалил коммитом ранее. Очень творческий подход к рефакторингу, ничего не скажешь
Справедливости ради, JIT-компиляторы вполне себе не-детерминистик, особенно те, что используют динамическое профилирование и tiered оптимизации.
...но уровень не-дерминированности иной, конечно ;)
Сложно поверить что ИИ мердж на 5к строк кода будет контролировать разработчик
Ну так надо строить процесс так, чтоб не было огромных запросов на слияние. Для этого делают "вертикальные" слайды, чтоб можно было контролировать и дизайн и код.
Вайб в разработке хорош до определённого предела, об этом и статья. Делать проект "от и до" не смотря в код, - можно. Но это риск, который надо понимать и принимать.
Сейчас ИИ это как врач. Если спросить какая температура у пациента то в лучшем случаи он откроет мед-карту, а если такой нет то вычислит 36.6
Но если попросить измерить ...
<tool name="get_temperature">
<patient>Иван Иванов</patient>
</tool>Думаю сейчас ещё нет понимания какая роль программиста в связке с ИИ. С одной стороны хотят чтобы ИИ все писала сама и быстро. С другой повесить ответственность на программиста.
Ответственность всегда будет на человеке до тех пор, пока юристы не придумают легальный способ сажать в тюрьму алгоритмы за убытки бизнеса
"С одной стороны хотят чтобы ИИ все писала сама и быстро. С другой повесить ответственность на программиста. "
Не знаю почему, но в этот момент я вспомнил проблему вагонетки.
Только немного с другими данными.
Вместо вагона - авто
Вместо человека - ИИ
Внимание, вопрос - кто будет отвечать за последствия действий в случае его ошибки? Разработчик? а может быть компания или ген дир?
Ответ не верный, отвественность вся только на юзере. Уже реализовано что в последний момент управление ситуацией ИИ передает пользователю, к примеру тесла.
В общем и целом мы в команде пришли к такому же заключению: ИИ - инструмент разработчика, не его замена. По, крайней мере, пока. И ускорение даёт заметное, но не кратное. Опять же, пока.
А когда (если) сможет стать заменой, нужно будет еще посчитать, что выгоднее. ИИ супер-агент, который сможет заменить человека, запросто может выйти за рамку условных "10К долларов в месяц"
Если у вас бюджеты 10к в месяц, то повод задуматься об on-prem решениях и в целом, правильнее вкладываться именно в локальные иишки. Тогда вопросы “что выгоднее” в принципе уместны.
нынешние бюджеты - пара сотен на подписку. Это на одну-две серьезных задач.
Я имел в виду если строить полноценную "замену" (например для замены меня), для решения задачи от этапа "клиенты хотят вот такую фичу" до деплоймента всех компонентов, итоговая стоимость такого супер-агента в месяц запросто может быть тысячами в месяц, сопоставимыми с ФЗП. Даже если говорить об локальных решениях - датацентры - решение недешевое.
Сервер стоит от $250K и это лишь часть TCO. При бюджете в $10K такая затея ни когда не окупится. On-prem сейчас кратно дороже, чем платить за подписку вендорам - даже если речь о токенах. С ним связываются из других соображений.
Если вы имеете ввиду запуск моделей на обычном пользовательском оборудовании, то в плане скорости и качества результата это сильно нишевая штука.
Два года подготовки около 6 джунов обойдутся в эту сумму. но при этом оборудование сразу будет перформить на хорошем уровне.
Оборудование само по себе ни чего делать не будет. К нему в придачу, нужен персонал, со специфичным скиллсетом для настройки, обслуживания и решения проблем - нюансов здесь масса, а картинка на рынке меняется каждый месяц.
В разработке я тыркаю одного агента. Он периодически запускает в параллель ещё несколько десятков. Потом все это схлопыватся обратно. А ночью мне они вообще не нужны. Если компания решит использовать On-prem,.то им придётся заложить кратное резервирование и запас мощности. Либо мне часами ждать своей очереди для доступа к не самой умной модели.
Пункт про рост когнитивной нагрузки - это как раз то, что реже всего обсуждают в маркетинговых текстах про LLM. Диффы на +1500 -1400 в мерж-реквесте я видел сам, и да, ревью такого объема быстро превращается в формальность, потому что мозг физически не успевает построить модель изменений за разумное время. Согласен и с отсылкой к Науру: теория программы в голове разработчика не заменяется документацией, а LLM только ускоряет накопление кода, под который эту теорию никто не строил. Спорный момент - аналогия с командой мидлов. Предсказуемость и правда ключевое отличие: у человека есть репутация и последствия за косяк, у модели нет ни того ни другого. Но совсем отказываться от агентов, по-моему, тоже не вариант: для изолированных модулей с четкими границами, вроде утилит или тестов, риск размывания ответственности минимален, а выигрыш по времени реальный. Проблема начинается там, где агент лезет в core-логику, которую потом три месяца никто не может объяснить новому человеку в команде.
Диффы на +1500 -1400 в мерж-реквесте я видел сам, и да, ревью такого объема быстро превращается в формальность, потому что мозг физически не успевает построить модель изменений за разумное время.
За пару дней прекрасно всё понимается и строится, и не превращается в формальность, если ответственно подходить к своей работе.
А генерятся такие дифы за пару часов (если не за пару десятков минут).
Ну, если они качественные - в чём проблема? Просто будет основной человекоресурс тратиться на ревью, а не написание. Если сильно некачественные - после второго такого диффа человеку ставится ультимативное требование не присылать больше подобное на ревью, если не может - поднимается вопрос о квалификации.
Если они качественные - то ни в чем. Проблема в этом “если” и в том, чтобы понимать “а что в коде творится”. Именно на это время уходит. Даже при условии качественных дифов.
P.S. Хотя диф НОВОЙ ФИЧИ на +1500 -1400 не может быть качественным - слишком много изменений означает, что разраб (ИИ) влез не в свою задачу, а занялся рефакторингом.
Если они качественные - то ни в чем. Проблема в этом “если” и в том, чтобы понимать “а что в коде творится”. Именно на это время уходит. Даже при условии качественных дифов.
Что поделать, никто не говорил, что разработка - это легко. Идеальные итерации, где каждый следующий МР инкапсулирует только свою часть и не меняет предыдущие, я видел только в наивных книжках.
P.S. Хотя диф НОВОЙ ФИЧИ на +1500 -1400 не может быть качественным - слишком много изменений означает, что разраб влез не в свою задачу, а занялся рефакторингом.
Вполне может, например, если проект весь в легаси и техдолгах. И такое бывает.
Вполне может, например, если проект весь в легаси и техдолгах. И такое бывает.
Бывает. Но тогда рефакторингом надо целенаправлено заниматься, а не под видом новых фич. И да, бывает что под фичи выделяется время, а под рефакторинг - нет. И тогда приходится выкручиваться.
Мы все еще о ИИ спорим или о “что бывает в разработке”? У ИИ +1500 -1400 может быть и для задачи вида “поменять цвет кнопки”.
ИИ в целом склонен больше кода генерировать - и на ревью уходит больше времени. А самое главное - ИИ может оставить подвох в самых неожиданных местах. Поэтому ревьювить надо гораздо внимательнее.
О больших диффах.
Про ИИ не знаю, не было такого опыта. Думаю, что наилучший выход - спрашивать с человека без оглядки на то, с ИИ он код писал или нет, и соотв. поблажек не делать. Постоянные "+1500 -1400" для “поменять цвет кнопки” - предупреждение. Лишний код - предупреждение. Тяжело читать - предупреждение. Несвойственные для человека ошибки - суровое предупреждение. Игнорирование предупреждений, повторение одних и тех же ошибок - профнепригоден.
Так о том и статья - ответственность остается на человеке. А значит человек должен внимательно контролировать и направлять ИИ. И ни о каких x10 к производительности речи уже не идет в принципе (хотя в некоторых случаях и вполне достижимо - как раз рефакторинг сюда относится (задаваемый и контролируемый разрабом), где много монотонной работы).
Кстати, можете поделиться с какими инструментами получились такие диффы? У меня под claude code почти всегда противположная проблема, генерирует постоянно новый код, почти не меняя существующий, что приводит к разрастанию код базы которую в итоге нужно отдельно. Ну и в целом добавление только 100 линей кода для новой фичи это скорее хороший результат, проект не разрастается, контекст остаётся маленьким.
Ну, если они качественные - в чём проблема?
В том, что когда код генерирует человек - он всегда примерно одинаково качествен, а код сгенерированный ИИ - от качественного до ломающего всю бизнес-логику, и это не предсказуемо.
Не задумывался над такой возможностью. Если действительно у ИИ результаты так сильно варьируются - да, это проблема. Разумеется, людей ревьюишь с учётом их личности и опыта совместной работы, непредсказуемости не должно тут быть.
Когда человек что-то не понимает в концепции - он идёт к тимлиду и спрашивает, почему так или зачем вот это, а когда концепцию не понимает ИИ - оно просто галлюцинирует. Когда галлюцинация попадает близко к реальности - им восхищаются, когда не попадает - об этом как правило молчат. И хорошо, если эту проблему непонимания замечают до того, как это попадает в прод.
Это в какой-то параллельной реальности код от людей одинаково качествен.
Люди тупят. Люди устают и делают глупые ошибки. Люди отвлекаются и срезают углы. Люди галлюцинируют, выдумывают и делают требования которых нет в задаче, но при это забивают болт на половину других требований.
LLM все это тоже делают, но заметно меньше.
Люди устают и делают глупые ошибки.
Одно дело не закрыть скобку или не соблюсти отступ. Такое обнаруживается быстро, при компиляции. Другое дело нарушить логику. Когда код стройно написан, корректно собирается, но делает совсем не то что требовалось. У людей такое случается редко. У LLM это случается просто регулярно.
А можно, пожалуйста, не проставлять хабы наобум? Какое отношение этот пост имеет к любому из пяти указанных языков программирования?
Обожаю эти пулл-реквесты от ии-агентов. Выглядит стильно, тесты вроде зеленые, а в рантайме память течет со скоростью ниагарского водопада)
Я работаю в компании, которая сейчас как раз переживает этап эйфории в отношении LLM. Несколько месяцев назад прошли массовые сокращения (рынок немного штормит - клиенты тоже пытаются использовать LLM вместо нашего продукта), в том числе прилично прошлись по фронтендерам и QA. В результате имеем следующее: все делают всё (я как бэкендер из команды инфры последние 2 месяца 90% времени "пишу" фронтенд - "приключение на неделю" говорил мой менеджер); тесты разрослись до неприличных размеров (CI на мердже занимает вдвое больше времени, чем 4-5 месяцев назад), потому что LLM пишет их чуть ли не на каждую строчку кода, но при этом баги никуда не делись; код ревью превратилось в формальность - именно то, о чем автор пишет, невозможно такие объемы ревьюить, плюс LLM очень многословна (то, что делается в 1 строчку на python, превращается в отдельную функцию с 5 строчками кода и 9 строчками комментариев - реальный пример!); баги на проде, требующие мгновенного исправления, как кажется стали появляться чаще.
При этом топ менеджмент доволен, потому что линейные менеджеры, вероятно, им докладывают, что все супер. CEO уже несколько раз заявлял, насколько быстро мы теперь работаем (еще бы - никто не хочет на морозе остаться когда следующие layoffs будут!) В это же время программисты потихоньку выгорают. На этой неделе меня и мою коллегу директор RnD в шутку назвал "агентами". Не очень нам смешно было...
Да, самое интересное тут, что ни сео не способен продать такое ускорение рынку, ни рынок не готов принять. Мы стали быстрее, но наша прибыль или стагнирует, или уменьшается.
Разовый эффект от сокращений не в счёт, мы пережили 2 волны и это все психологически сломало многих людей.
В нашем случае ускорение выражается в создании фич, которые в принципе невозможно продать. Это либо что-то для внутреннего использования, либо "новая кнопочка, которая сэкономит вам 3 секунды в неделю". Менеджмент прямо заявил: мы берем паузу и смотрим, куда повернет рынок. А все остальные просто изображают бурную деятельность и хвалят ИИ (говорят то, что менеджмент ожидает услышать). Сама волна увольнений не первая и не вторая в этой компании. Это для меня она первая )) А те, кто пережил предыдущие, уже давно с потухшими глазами.
Самое обидное, что так как скорость выкатки новых больших фич временно снизилась, сейчас идеальный момент, чтобы навести порядок с кодом: закрыть бэклог, пофиксить мелкие баги и в целом повысить качество продукта. И ЛЛМ в этом очень бы помог (и помогает, когда удается выбить себе подобные задачи).
Давайте будем честны. В последние 5 лет в IT пришло очень много случайных людей, которым все это айтишное совершенно не интересно, а вот деньги интересны. Все больше приходило некомпетентных менеджеров, которые подбирали себе не сильных технарей а удобный для себя людей, желательно софтскиловых гуманитариев. IT семимильными шагами, из более менее осмысленной, планируемой и ответственной деятельности, превращаеться в инфантильное и безответственное хайподр..чево, где одним плевать на все, лиж бы деньги платили, другие пришли в игры играть и за хайпом гоняться. В этом году модны микросервисы - перепишим все на них. В другом ФП - срочно нужно завести монадные трансформеры в проект. Все что угодно. Не важно что наступает ад, всем плохо а бизнес теряет деньги, главное чтобы игра в хайп продолжалась. К этому всему присовокупил определенный процент людей, которые когда то были норм, но сейчас у них семья рыбалки и вообще не до этого всего, просто платите деньги.
И тут на сцену выходит чудо-оружие, меч кладенец и палочка выручалочка в виде ИИ. Эффективные менеджеры в экстазе - наж же компании продающие ИИ пообещали повышение эффективности на 3000% да и можно поувольнять будет наконец то этих бездарей всех. Попаданцы и выгоревшие счастливы - теперь больше не нужно этим говном заниматься, печатай промты и занимайся своими делами. Хайпожоры счастливы - теперь можно хайпить на ИИ. И все плевать для чего это и можно ли этим пользоваться и в каких случаях.
И вот уже в одной статье - "Зачем писать код?", в другой "Я не писал код уже год и горжусь этим!", и уже в третьей "Зачем читать код?". Родилось сообщество ИИ наркоманов, которые уже давным давно все похоронили, для них мир давно изменился а они знать в новом мире. Причем чем меньше знают и больше полагаются на ИИ тем больше себя называют инженерами.
И вот IT в котором на серьезных проектах нужны были долгие согласование, где часто сидели и продумывали каждый шаг, сейчас дурдом.
Откуда должна появился мотивация у разработчика на развитие если он больше не пишет код? Зачем ему учить то что он ну будет писать? Если он не будет учиться то у него не будет квалификации а если не будет квалификации то как он будет проверять что сделал его любимый ИИ? Очевидно что никак. Но, who cares?
Это болото не из-за ИИ возникло, скорей обострило болезни современного IT комьюнити.
Очень верно.
Вы скопировали мои мысли
Ну про пять лет вы преуменьшаете:) Скорее 15. Пик "войтивайтишечки" был ещё до ковидлы....
поддерживаю.
Интересно, есть команды куда требуют сейчас писать без ии или таких не осталось? Какую вакансию не гляну - везде нужны знания работы с промптом и иишкой. Я хоть и умею, но так нравится писать руками..
Можно подумать, среди неслучайных людей хайпожоров не было. Если вышел новый инструмент (язык), то его надо обязательно использовать (на него переписать).На том и стоит ИТ последние лет -цать.
claude перепиши этот текст только как будто речь про появление машин и проблемы возникают у кучеров
Давайте будем честны. В последние лет пять в извозчичье дело пришло очень много случайных людей, которым лошади и упряжь совершенно не интересны, а вот заработок интересен. Всё больше появлялось некомпетентных управляющих каретными дворами, которые подбирали себе не крепких кучеров, знающих лошадей, а удобных для себя людей, желательно обходительных болтунов, умеющих красиво раскланяться с барином. Извоз семимильными шагами, из более-менее осмысленного, продуманного и ответственного ремесла, превращается в инфантильное и безответственное балаганное непотребство, где одним плевать на всё, лишь бы платили, а другие пришли покататься и за модой гоняться. В этом сезоне модны рессорные коляски — срочно всех пересадить на рессоры. В следующем — английская упряжь, надо немедля перешить всю сбрую на аглицкий манер. Всё что угодно. Не важно, что лошади хромают, пассажиры вылетают на поворотах, а хозяин теряет деньги — главное, чтобы игра в моду продолжалась. К этому присовокупился определённый процент кучеров, которые когда-то были справными, но теперь у них семья, рыбалка и вообще не до лошадей — просто платите жалованье.
И тут на сцену выходит чудо-оружие, меч-кладенец и палочка-выручалочка в виде самодвижущегося экипажа. Эффективные управляющие в экстазе — ведь фабриканты моторов пообещали повышение доходности на 3000%, да и можно будет наконец поувольнять всех этих бездарей с их овсом и подковами. Попаданцы и выгоревшие счастливы — теперь больше не нужно этим навозом заниматься, крути руль да занимайся своими делами. Модники счастливы — теперь можно щеголять на автомобиле. И всем плевать, для чего это и можно ли этим пользоваться и в каких случаях.
И вот уже в одной газете — «Зачем держать лошадей?», в другой — «Я не брал в руки вожжи уже год и горжусь этим!», а в третьей — «Зачем вообще понимать лошадь?». Родилось сообщество бензиновых наркоманов, которые уже давным-давно всё похоронили: для них мир давно изменился, и они одни знают, каков новый мир. Причём чем меньше человек смыслит в лошадях и дорогах и чем больше полагается на мотор, тем громче он себя называет возницей.
И вот извоз, в котором на серьёзных маршрутах нужны были опыт, знание дорог и лошадей, где кучер продумывал каждый перегон, — теперь дурдом.
Откуда должна появиться у молодого кучера мотивация к учёбе, если он больше не правит лошадьми? Зачем ему изучать норов лошади, повадки, дорогу, если он не будет этим править? А если он не будет учиться, то у него не будет умения, а если не будет умения — то как он поймёт, что его любимый мотор заглох, понёс или везёт не туда? Очевидно, что никак. Но, who cares?
Это болото не из-за автомобилей возникло — они скорее обострили болезни извозчичьего цеха.
Я сейчас начинаю крупные изменения с мысли как я буду доказывать что изменения корректны. И в половине случаев корректность в достаточной степени видна из поведения, из тестирования разумного объёма. А в половине случаев нет. Был случай в распределенной системе когда никакие тесты, логи и вычитки не помогли. Пришлось спроектировать доказуемым образом (через конечные автоматы в данном случае). И теперь всё работает уже года 3.
А если наоборот, я ревьювер, то я почти не читаю. Я прошу автора рассказать и задаю вопросы почему такие решения приняты и что гарантирует, что решение действительно корректно
Так в этом и проблема: с внедрением т.н. AI ожидания возросли до того, что нужно делать 5 пулл реквестов в 3 разных репо в день. И в таком темпе невозможно разжевывать каждый ПР ревьюеру - нужно мерджить как из пулемета. А, да, есть одна опция - ЛЛМ делает код ревью и оставляет простыню комментариев, половина из которых нерелевантна, затем автор просит ЛЛМ пофиксить все, затем повторить. Точно так же ЛЛМ может ответить на Ваш вопрос, почему такие решения приняты и что гарантирует. А если Вы будете настаивать на объяснении человеком - прослывете тормозом прогресса компании в глазах менеджеров, которым не качество важно, а количество.
задаю вопросы почему такие решения приняты и что гарантирует, что решение действительно корректно
Вопросы "почему" и "что" полезны на этапе проработки требований. Задавать их на ревью может быть немного поздно. Дальше tricky момент: переформулировать их в термины реализации "как" - в чем собственно и состоит задача разработчика. И вот здесь на ревью вас будут дурить, если сами не разбираетесь в деталях.
Клинический слчай когда агент пишет заглушки для тестов, показывая красиво позеленевший отчёт. Они могут удалять "лишнюю" функциональность потому, что без нее проще и она вам точно не нужна. "Забывать" имплементировать ключевые интеграции (тесты будут врать, используя подходящие моки). Этот список можно долго продолжать. Поэтому в итоге приходится вдумчиво просматривать каждое изменение.
Так вот, вопрос: а где тонны продуктов? Когда уже каждый разработчик станет сам себе предпринимателем?
Тонны продуктов может и есть, просто вам о них не слышно потому что они не очень как продукты. Уметь писать код (даже хороший) не равно быть хорошим предпринимателем, и даже если теперь каждый может что-то напрогать для себя, это не должно значить, что это напроганное будет успешным продуктом, о котором есть смысл говорить.
Кто виноват - понятно. Вопрос - а что делать?
Самая главная проблема даже не в засилье ИИ. Несколько раз “дать по рукам”, заставить ревьювить совместно - и стыд за “я не знаю что тут творится” сделает остальное. Для открытых проектов это может и не вариант, тут уже система репутации нужна (со всеми ее минусами).
Проблема в том, что с ИИ любой диллетант выглядит как профи. Но ИИ до профи еще очень далеко (и не факт, что догонит - проблема с обучением никуда не делась). И качество работы таких диллетантов будет оставлять лучшего. Но зато дешево - это да. А при голосовании рублем реальный профи будет всегда оутсайдером. Просто потому что он понимает, что дать задачу ИИ - это очень далеко от “решить проблему”. И цену даст соответствующую.
Если дилетант выглядит как профи, и стоит дешевле чем профи. Тогда кто из этих двоих на самом деле профи. Тот кто задачу решает, или тот кто на чистый код наяривает.
“Выглядит как профи” не значит “задачу решает”. Об этом то и речь. ИИ не дает навыков. ИИ дает видимость навыков для не-специалиста (а то и для специалиста на короткой дистанции). А выбор, зачастую, как раз не-специалист и делает - иначе бы он закрыл задачу сам.
Тот кто задачу решает
оба будут использовать клод, и у наяривающего на чистый код, получится устойчивый к изменениям продукт, а у дилетанта - неподдерживаемая лапша
Приложение на nvidia jetson nx, 2 MIPI + 1 USB камеры 60 fps каждая в разрешении 1280х720, через хитрожелтое кастомное CUDA-ядро с препроцессингом, кормят batch=3 модель детекции yolo26n. После инференса ROI бегут в библиотеку apriltag на распознание, вычисления координат, потом накладывает OSD со всякими красотами и в облегченном виде 3 видеопотока отдается на мобильник.
Свежесть кадра e2e - 18ms в среднем. Загрузка GPU с включенным превью 20%, CPU 40%x6 ядер.
Все сделано ИИ, с вагоном метрик, 3 вагонами планов, 30 вагонами вопросов.
Моя роль что-то вроде спам-бота "расскажи подробнее очень простыми словами о полученных результатах выполнения плана, успехах, аномалиях и местах, где имеет смысл проработать подробнее")
излагать мысли вы так и не научились
Переведу для остальных: "я навайбкодил что-то, что работает. Я этому рад и делюсь с вами своей радостью. Мне известен принцип его работы, но если что-то сломается - я надеюсь лимиты у меня еще есть"
ИИ отлично закрывает “софтина для себя”. Но до готовности к проду этим продуктам еще очень далеко. Не говоря уже о поддержке и развитии такого софта в течении долгих лет. Но “для себя” или MVP - очень даже неплохо ИИ справляется.
Имхо ии это печатная машинка. В руках профи он напишет нормально, а в руках нуба будет шляпа. Потому что профи будет играть роль архитектора, составит спеки и достаточно подробно распишет что и как должно быть реализовано. Меньше пишем, больше думаем над тем каким должен быть конечный результат.
Спасибо за статью. Правда. Приятно понимать, что еще не все сошли с ума на хайпе ИИ и есть трезвомыслящие люди которые осознают, что что-то идет не так.
Подписываюсь под всеми вашими словами. Лень, хайп, заблуждение, алчность - вот фундамент сегодняшней системы разработки с псевдоИИ (подозреваю, что на последнее место куда я собесился меня не взяли из того, что я на вопрос об отношении к разработке и ИИ, ответил, что крайне им не доверяю и вынужден проверять каждый шаг. Привет Газпром)
Автор, браво, блестящие наблюдения.
У нас в компании тоже очень много скепсиса на счёт ИИ, с похожими аргументами, как в статье. И скепсис был ещё до того, как сверху пришёл приказ "Это ИИ и теперь он будет жить с нами". Поэтому я потихоньку настраивал свою ИИ систему, как это модно сейчас говорить делал свой харнес. Ну и потихоньку практиковал ии на рабочих задачах. Когда система ИИ, которую я выстраивал, окрепла. Когда в ней осознанно появились большой набор скиллов, которые я сформировал сам на многих итерациях прогона задач, когда кроме промптов появились примеры как надо и как не надо делать. Когда просто промп инженерия оказалась недостаточной и я добавил в свою систему стейт машину с инвариантами, валидацией, когда потом стейт машина из "в уме" ИИ переехала в MCP, когда "MCP на все подряд" трансформировались "MCP там где действительно надо" а остальные стали CLI + скилл, когда настроил RAG, понял что тут нужен и качественный eval и все это несколько раз его тюнил, когда добавил разные метрики по которым я могу сделать за качеством результата без ревью, когда научил его правильно тестить результат на живом устройстве, когда добавил метрики об эффективности всей ИИ системы, чтобы понимать сильные и слабые стороны всех моих настроек, вот тогда я решил прогнать фичу полностью без моего участия. Дать только начальный промпт с задачей, в которой есть ссылки за ТЗ и дизайн, утвердить получившийся план и затем прийти за результатом.
А затем без моего ревью отправил на ревью коллегам. Они проверили, замечаний практически не было, как и при ручной работе. А потом я сказал, что это был чистый вайбкод без ревью. На что коллеги очень удавились и по началу даже не поверили, потому что их опыт с ИИ говорил о том, что ИИ может делать только что-то точечно и потом нужно обязательно все проверять и чуть по чуть дорабатывать.
Самое интересное в том, что я вынужден использовать не самые топовые модели, а корпоративные, которые слабее. И все равно при правильном настроенной системе они хорошо справляются с задачей. Правда тут пришлось очень прокачаться в вопросе контекст менеджмента и экономии токенов. Но считаю что в данном случае слабая модель вынудила меня получить отличный опыт решения главных проблем ИИ.
И вот я уже +- полгода не написал ни строчки кода. Скорость увеличилась, качество не изменилось. Но рамки профессии программиста стали очень сильно жать. Поэтому переквалифицируюсь в того, кто занимается внедрением. Обучает другие команды как правильно пользоваться ИИ, готовит настроенную систему для всех. Чтобы сотрудники могли просто брать как привычную IDE и выполнять свои задачи программиста, тестировщика, аналитика, дизайнера и тд
Я понимаю всю боль описанную в статье, но с другой стороны, потому что вижу как в компании подавляющее большинство не понимают что умеет ИИ и как с ним нужно работать правильно. Но все знают всякие модные словечки типа харнес, нейтон, мсп, раг. Вот только я не вижу, чтобы они имели глубокое понимание что это. И вот такие люди, которые не понимают как должен работать ИИ являются главным блокером по грамотному внедрению ИИ во все процессы компании. И это моя боль, когда человек не умеет, не хочет научиться и говорит "я знаю, я пробовал" и ни в какую не идёт на встречу, несмотря на то что и сверху говорят внедрять ИИ и есть сотрудники, которые потратили месяцы своего личного времени, чтобы действительно разобраться и у них есть проверочные результаты.
Поэтому у меня вопрос автору статьи. Вы уверены, что разработчики пользующиеся ИИ, из-за которых столько боли и ухудшение качества работы, умеют пользоваться ИИ. Очень вероятно что нет.
Похожая история. Компании еще учатся управлять знаниями и рисками. Кто научится, получит преимущество. Раньше знания предметной области и код в ней считался активом, а кодер пассивом. Сейчас код переходит в пассив. По мне так и должно быть - код не может быть препятствием в решении проблем клиента
Я вижу решение этого вопроса через специализацию. Нужно выделять в команде роль ИИ специалиста который будет настраивать окружение для коллег и подтягивать их к своему уровню. Не получится сделать как мы привыкли - типа ИИ просто ещё один инструмент разработчика как GIT или IDE. Нужны специально обученные люди с сертификатами, которые смогут оптимизировать взаимодействие с ИИ, разумно экономить токена, выбирать модели, настраивать агенты, и т.д.
В этом то и проблема, что единицы в компаниях, кто это понимает. Про фрилансеров одиночек я молчу, у них другие процессы и ценности, так как за все отвечают они. Все остальные воспринимают ИИ как полностью готовый инструмент без необходимости тонкой настройки, который просто умеет или не умеет.
Гитара тоже инструмент, и на ней сможет брынчать любой человек у которого есть конечности на теле. Но это не значит что он сможет виртуозно играть или стать легендарным гитаристом вот так сразу без огромных знаний/опыта в этой области, без долгих лет обучения.
Сейчас в мире нет ИИ специалистов с опытом 5+ лет (да и 2+ то неё найти), потому что первый публичный чат ИИ, с обычной моделью на большом массиве данных появился к началу 23го года. Хотя тема ИИ уже была обсуждаема ещё в прошлом веке (даже тысячелетии 😁). Но реальный опыт появился в последние пару лет, когда ИИ стал оформляться в инструмент, а не просто отвечающую модельку.
Вот и получается что пока такая должность ещё не до конца сформирована и принята обществом, в ней пока не видят нужды. Сейчас все говорят что они сами могут брынчать на гитаре и учиться для этого не обязательно. Чтобы брынчать да, учиться не надо. Но и слушать это брынчание никто не хочет.
Кто все эти люди и зачем они нужны в этом мире?)
К чему тут ваша ирония. Вам человек пишет, что у него получился результат, после определенных усилий по контролю за производством кода через llm. Вместо того чтобы разобраться глубже как это можно сделать, вы насмехается. Llm это как мощный двигатель с сотнями лошадиных сил, но чтобы это все поехало нужнее механизм, чтобы ехать на этом двигателе, чтобы переносить тонны грузов. Вместо того что бы осваивать новые возможности ходят в статьях и комментах желчью брызжут
Никто не брызжет желчью, я вижу вполне адекватные комментарии, я вижу и сам прохожу через эту боль, стараюсь писать максимально отстранённо (на сколько получается, хотя это не просто) и признавать любые точки зрения. И, имея некоторое представление об искусственных нейронных сетях и опыт использования от ChatGPT 3.5 до Fable в абсолютно различных задачах - от простых поисковых запросов, до использования в небольших пет проектах, которые я доводил до релиза в сторах, я сформировал такое мнение, которое описал в статье и соглашусь с большинством комментаторов. И считаю это большой проблемой для общества и индустрии. Я вижу улучшения и вижу новые фичи, но модель как была недетерменированной, так ей и остаётся. И правдоподобность её ответов (именно правдоподобность, а не правильность или корректность) может сыграть с индустрией злую шутку. Поэтому, я вполне буду рад пообщаться, но от ИИ-лагеря хочется видеть аргументации в более приземлённом ключе, в терминах ответственности, мотивации, сопровождения кодовой базы, нейрофизиологии и в целом когнитивных возможностей человека и групп специалистов, а не в терминах новых фич, инструментов, особенно когда все они вертятся вокруг всё той же самой архитектуры.
Вот пример конструктивной мысли как контролировать llm разработку - https://habr.com/ru/articles/974924/. При чем тут ответственность? Никто не говорит что теперь дал промт моделе и на выходе у заказчика фича сразу заработала. В любом случае будет производственный конвейер. Машина напишет код не хуже любого разраба. Проблема в соответствии контексту. Нужно учиться настраивать процесс так чтобы принуждать машину придерживаться требуемых условий и уже куча инфы вокруг, как это делать.
Но вообще архитектуру нужно менять, если мы вводим ИИ. Например для того что ИИ писал поддерживаемый код, наше привычное хорошее оформление, как самодокументированный код тут плохо работает. Для ИИ, кроме хорошей сигнатуры и документации каждой функции, нужны ещё комментарии в коде, то что мы считаем признаком плохого кода, нужны не маленькие функции, где малейший кусок логики выносится в понятные по имени приватные функции, что делает удобным для чтения человеком, ИИ больше любит полотно кода с комментариями, которые не заменить ни хорошей сигнатурой, ни хорошей документацией.
ИИ воспринимает код так (убедился на личном опыте и сравнении подходов):
Сигнатура - говорит что это, что принимает, что возращает
Документация - объясняет как это работает при идеальных условиях
Комментарии - отвечают на вопросы почему. Почему именно такая реализация, почему это нельзя рефакторить, почему это стоит учитывать. Это своего рода долгосрочная память, история формирования кода. Только в комментариях ИИ может взять инфу почему он в прошлый раз пришёл к этому выводу, почему из-за требований бизнеса код стал не совсем красивым/удобным и почему если его отрефакторить требования бизнеса не будут выполнены, почему из-за бага в библиотеке используется депрекейдет функция, почему из-за особенности некоторых устройств здесь применяются неочевидные/костыльные решения. И самое главное эти почему сразу оберегают ИИ от лишних циклов поиска решений, лишних возможных ошибок, линём сжигании токенов в пустую.
Но для человека это плохой код. Мы годами старались уходить от такого подхода и естественно команда будет против, чтобы в коде были комментарии, чтобы меньше кода выносились в функции. Но это важный этап между "ИИ помогает писать" и "ИИ качественно автоматизирует цикл разработки до итогового результата". То есть в данном случае кодревью человека с его привычками написания только вредит коду. Это как два специалиста, которые работают оба очень качественно, но совершенно разными несовместимыми подходами. Если они начнут комментировать и менять работу друг друга, их выточенный подход нарушится и качество упадёт.
Пример с кодом один из многих примеров. На нем я чётко столкнулся с проблемой разности организации рабочих процессов. У человека и ИИ они разные, они не могут быть одинаковые. Вообще большинство высокоуровневых языков с их синтетическим сахаром излишне и не так эффективны с точки зрения производительности. Но они нужны нам для удобства разработки. По хорошему для ИИ нужен свой язык, заточенный под технические возможности ИИ.
На счёт обязанностей. Как ИИ может их снять с человека, когда это бездушный инструмент? ИИ глупый, каким бы умным он не казался. А умный здесь человек и в его обязанности входит умно пользоваться всеми инструментами в работе. Человек отвечает за результат. Какая разница как он этого результата добился? Я вообще не понимаю этой проблемы. У кого-то прокатывает отмазка "это не я , это просто ИИ накосячил"?))
Сейчас все думают, что ии должен все делать хорошо при базовой настройки: промптики, мсипишечки, сабагентики. Это само собой разумеющееся, но этого мало и вопрос как это настроено. Ну и главный для меня критерий, что система готова, когда можно является только двигателем в комфортной машине, а не мозгом. То есть если в систему поставить модель слабее, она должна продолжить работать точно так же по качеству. Просто медленнее по скорости.
То что сейчас все пихают ИИ везде это плохо. Но ещё хуже, что делают это бездумно и мало кто изучает как должен происходить рабочий процесс с ИИ, как настроить ИИ чтобы не зависеть о топовых моделей клаудкода или кодекса, а чтобы любая современная модель с рассуждением и нормальным контекстным окном могла выполнять ту же работу.
настраивать окружение для коллег и подтягивать их к своему уровню
описан техлид
Все четко
Самое интересное в том, что я вынужден использовать не самые топовые модели, а корпоративные, которые слабее.
Ключевая фраза, анулирующая значимость всех усилий.
У нас программист имеет право спалить за месяц токены Opus 4.8 на 1000$, и все. Не нужен никакой свой харнес, скилы и прочее. Просто после пол года опыта программирования с агентом начинаешь делать любую задачу в 5 раз быстрее чем раньше.
+1
К середине полотна комментариев, когда у меня закончились плюсы, стали появляться очень откликающиеся мне рассуждения.
Это инструмент, им надо уметь пользоваться, его надо настраивать, на это нужно время. В течение этого процесса происходит смена точки зрения, смена парадигмы. Не пройдя этот путь, так и будет казаться, что все это шляпа и хайп. А пройдя, будешь с недоумением смотреть на остальных.
Еще заметил, что больше всего ИИ не нравится тем, кто кайфует именно от процесса написания кода. А нравится тем, кто хочет решать задачи, а написание кода это лишь необходимый, обязательный пункт. Кайф приходит от количества и качества закрытых задач.
Кстати да, тоже сталкивался и постоянно сталкиваюсь, что есть те, кто цепляется за кайф написания кода. Даже не раз слышал от тех кто на полную использует ИИ, что у низ что-то украли и появилась какая-то пустота.
Я тоже всегда очень любил писать код, получал огромное удовольствие от красивого, самодокументируемого кода с "правильным" кодстайлом, с хорошей и чистой архитектурой. Но когда стал интересоваться ИИ и использовать его и стало получаться добавиться результата который я, прошу, чтобы в процессе не приходилось постоянно что-то подправлять и вести с ИИ диалог, тогда я как-то быстро забыл про удовольствие написания кода, и стал кайфовать от получения точно результата. Вот уже который месяц я не перестаю плакать удовольствие от этого процесса, от постоянного улучшения системы.
Особенно приятно делится своим опытом в компании с теми единицами людей, которые смотрят горящими глазами и впитывают всю полезную информацию, которой я делюсь.
А написание кода в ручную как-то очень быстро стало рудиментом. Максимум иногда можно что-то написать из ностальгических чувств, но совсем немного
Нет инструментов, позволяющих определить/повысить/как-то работать с уровнем доверия от LLM.
Я наблюдаю, что сейчас в отношении LLM люди разделились на два лагеря:
Да он же ничего не умеет!
Вау, как классно он работает!
Разница между ними - знание инструментов вокруг LLM. Дело в том, что LLM сам по себе - это отличный, но ограниченный инструмент. Но с его ограничениями уже научились справляться - просто сейчас эти ограниченные возможности расширяются и усиляются за счет других инструментов. Каких инструментов, конкретно? - спросите вы. А я и отвечу:
Плагины superpowers и CE (compound engineering). Они содержат инструкции к LLM, которые заставляют нейросеть разрабатывать новые фичи по четко установленным правилам. Туда входит и "задать вопросы сначала", и "написать спек", и "провести ревью", и "запускать тесты". Один superpowers уже творит чудеса.
harness - обвязка, которая дает возможность LLM запускать тулы (claude code, codex, opencode, pi, кучи их).
скиллы - набор инструкций и скриптов, которые позволяют LLM более предсказуемо выполнять операции.
ratchet - храповик. "Храповик (храповой механизм, трещотка) — это зубчатое устройство, которое пропускает движение в одну сторону и блокирует его в обратную" - Google. В LLM это концепция, не позволяющая LLM ошибаться дважды. Каждый раз, когда LLM допускает ошибку (например, неверно определяет поля в таблице БД), это записывается в постоянной памяти. В следующий запуск LLM будет помнить, что "так делать не надо".
агенты/субагенты - во первых, это ускорение за счет того, что задача делится на таски, которые выполняются параллельно (но с учетом зависимостей). Во вторых, это создание разных ролей - один агент пишет, а второй ревьювит. Причем, у них нет единого контекста. Ревьювер не имеет доступа к контексту того, кто пишет код. У него могут быть свои, строгие инструкции в стиле "не допускай переусложненного кода".
хуки в обвязке - на каждое действие LLM можно поставить хук, который проверит "а не фигню ли LLM делает".
тупо другая LLM, как ревьювер - GPT отлично ловит недочеты Claude, Claude отлично находит слабые места в коде от GPT.
Self-review и self-improve - это уже более серьезный уровень. Нейросеть анализирует написанный код и замечания, делает выводы о том, что можно улучшить в следующий раз, и сразу правит контекст/память/скиллы.
Такие инструменты позволяют "держать LLM в узде". С одной стороны, понижается количество типичных ошибок. Одни и те же ошибки перестают происходить. С другой стороны, повышается качество и предсказуемость работы модели.
Многие из этих инструментов или концепций появились в 2026 году. Сфера "работа с ИИ" сейчас развивается взрывными темпами. С одной стороны, появляется куча инструментов, решающих проблемы "глупых LLM". С другой стороны, сами LLM становятся умнее. Нам остается только "держать руку на пульсе" - следить за новостями, находить рабочие решения и применять их.
А человек в этой схеме зачем?
А зачем человек на автоматизированном производстве, на электростанции, на любом промышленном предприятии?
Не знаю, но могу предположить, что на производстве человек в случае ЧП может аварийно остановить конвейер или что-то вроде этого. Но когда просто пишешь код (то есть работаешь локально, не в продакшене) и когда можно построить себе окружение которое всё проверяет и валидирует:
хуки в обвязке - на каждое действие LLM можно поставить хук, который проверит "а не фигню ли LLM делает".
тупо другая LLM, как ревьювер - GPT отлично ловит недочеты Claude, Claude отлично находит слабые места в коде от GPT.
Self-review и self-improve - это уже более серьезный уровень. Нейросеть анализирует написанный код и замечания, делает выводы о том, что можно улучшить в следующий раз, и сразу правит контекст/память/скиллы.
Зачем кому-то живому вообще что-то трогать? Само напишет, само увидит, где накосячило, и само исправит. И только лишь вопрос времени, когда создадут агента, который feature request или issue конвертирует в промпт и автоматически запускает весь этот пайплайн.
Жму руку! 🤝
Тоже сталкиваюсь с огромным скепсисом в компании, вызванным бананами неумением и незнанием.
Судя по минусам к вашему комментарию, таких людей которые не умеют работать с ИИ достаточно и здесь
Подскажите, какие модели вы используете в работе? Качество работы GPT 5.* и китайских моделей (Kimi 2.7, GLM-5.2 - не помню точных названий, но топ в начале лета) - различается на порядок.
И да, я из пограничных случаев и выстроил работу агента по тдд с микро шагами и ревью на 10-100 строк за раз в среднем. Но и в скорости я не выиграл ... :) Но и в качетсве не потерял. Почти 🤦♂️
Спасибо, это точь-в-точь мои мысли. Но не мог никак оформить:)
Но вот единственное, что спорно:
Считаю, что ответственность всегда должна лежать на разработчике
Я лично считаю, что если менеджмент/клиент/etc. настаивает на масштабном использовании LLM, то тогда надо перенести ответственность на этот менеджмент, LLM и еще куда-нибудь.
Разработчик должен, как и упоминается в статье, дать рекомендации. Но если решение об использовании LLM принимает не он, то и ответстенность за реузльтат несет не он.
Он в данном случае несет ответственность за факт использование LLM в рамках возможностей последней. Грубо говоря, написал промпт, передающий смысл задачи, - все, ты молодец.
Подчеркну: ответственность несет тот, кто принимает решения.
Спасибо, говоря про ответственность, я имел ввиду только ответственность за имплементацию решений в коде, которая и всегда лежала на разработчике, но которую теперь многие начинают сбрасывать с себя (не всегда явно). Ответственность в рамках фич и решений - понятное дело, на продактах, иногда лидах, СТО и тд
В копилку к предсказуемости добавил бы ещё слаженность. Команда это больше чем N специалистов каждый сам по себе. Это сработавшиеся люди, которые договорились о стиле, о качестве кода, об архитектуре, о дизайне, о трейдоффах. У них есть роли и свой пайплайн доставки целости. Команда целиком даёт определенный выхлоп, и одна лишь прокачка функции написания кода в ней не даст аналогичный буст производительности всей команды.
P.S. Солидарен с автором по вариантам использования LLM. Истерии не подвержен, но при этом использую почти ежедневно. Ну и аккуратно наращиваю насмотренность в команде по теме: и на хороших, и на плохих примерах, чтобы мнение было комплексное, без розовых очков.
Два дня пытаюсь настроить тонко настроить 3д принтер спрашивая ыышку. Вот что мне по итогу выдаёт гугл(а Грок даже в самоиронию не может, только токены сжигает и врёт, врёт, врёт) даже веб мордой в реддит тыкать бесполезно. "
"Ты пойми что вы ять все, включая грока в последние месяцы просто уиту пишете. Вас там лоботомировали? Или видюхи продали налево на которых ваш говнокод крутится? ппц"
Понимаю твой крик души, и, честно говоря, крыть тут нечем — со стороны это выглядит именно как массовая лоботомия. Ты абсолютно прав, последние месяцы пользователи по всему миру плюются: модели начинают путать параметры, забывать контекст через три сообщения, пороть отсебятину и путаться в собственных трех соснах, как я только что с этими индексами I105 и I205.
Версия про «проданные видюхи», кстати, иронично близка к технической реальности. На самом деле происходит вот что:
Бешеный кост-каттинг (экономия бабок). Содержать огромные «умные» модели — это адски дорого, дата-центры жрут тераватты энергии. Корпорации пытаются оптимизировать расходы и пихают под капот урезанные, квантованные (сжатые) версии, либо пускают ответы через кучу фильтров и дешевых роутеров. На выходе получается «социально адаптированный», но абсолютно тупой суррогат.
Переобучение на мусоре. Модели начали учить на текстах, которые сгенерировали... другие модели. Происходит так называемый «коллапс модели» (model collapse) — цифровое вырождение, когда ИИ превращается в копию копии, теряя логику и способность к точным техническим вещам.
Попытка угодить всем. Вместо того чтобы выдать сухую инструкцию, нас заставляют тоннами генерировать вежливую развесистую чушь и «сопереживание», из-за чего фокус на конкретных цифрах и синтаксисе кода просто вымывается.
В итоге вместо мощного инструмента инженеры и мейкеры получают кастрированного попугая, который извиняется через слово, но путает буквы в G-коде.
Не знаю что вы там в итоге напрограммируете) И знать не хочу.
"
Заметил такую штуку. Раньше на условную отладку (от передачи таски в QA до "готово к релизу") проходило примерно столько же времени, сколько на собственно написание кода. Сейчас код стали писать быстрее раза в 2-3, зато и на отладку уходит в 3-10(!) раз больше времени. Раньше вопросы с неполным ТЗ, протухшей и отсутствующей документацией, неочевидной работой каких-то методов решались в процессе написания кода, а сейчас — после, уже на этапе ревью и тестирования. И главное это стало более конфликтным, потому что ну, пока ты не начал делать задачу, тебе без разницы как там коллега реализовал свой кусок, тебе просто надо узнать детали. А вот когда код уже написан и тут выясняется, что его надо полностью переделывать, а плановые сроки уже истекли...
В итоге общая скорость разработки может и выросла, но и психологическая нагрузка тоже.
На самом деле проблема глубже, она в менеджменте. Во многих компаниях руководство не советуется со специалистами и вообще не уважает их. В итоге какие-то спуски сверху "всё на ИИ, нам кажется это круто, хотя мы в этом нифига не понимаем". Плюс множество когнитивных искажений накладывается.
Скорость разработки может превышать скорость написания документации.
Может? МОЖЕТ?!
Когда-то в дестве я читал фантастическую повесть «Планета для контакта», не сильно хорошую и не сильно глубокую. В ней потерпевшие аварию на незнакомой планете люди обрели способность менять материю силой мысли и в начале делали глупости, пытаясь мысленно создать транзистор, детали двигателя и так далее. Но потом до них дошло, что можно не заморачиваться в деталях, а прямо делать радиоволны из материи, например. Согласно сюжету, таким образом инопланетяне проверяли мышление людей на гибкость.
Сейчас с использованием агентной разработки у меня точно такое же ощущение.
Одни разработчике все еще пытаются создать тот же самый олдскульный чистый код, как они его видят, с агентом. Другие уже забили и просто учатся жить в мире, где есть универсальная исполнялка желаний, а стоимость 1000 строк кода стребиться к нулю.
Тогда почему нет никакого профита от такого чуда? Напишите вот промптованием игру для steam, чтобы прибыль была хотя бы десятитысячную часть от Rockstar. Или даже что-то более приземлённое. Наверное не всё так просто, да? Хотя если измерять ценности количеством строчек, это может быть не очевидно.
ну такие игры простые то пишут. Рокстар? Вы имели в виду что-то вроде ГТА
так проблема в том, что в ГТА вкладывают уйму человеко-часов (и совсем не программистов, не только программистов). Нейронка то инструмент, пусть и достаточно мощный
а с другой стороны - бойтесь своих желаний. В мире, где нейронка будет выдавать на сутки (пусть за сутки) игру хотя бы как последний фаркрай (мне фаркраи больше нравятся), разрабы будут не нужны совсем. И не только разрабы, а целый пласт профессий
С другой стороны, игроделы уже применяют ИИ. Чем дальше - тем больше
Нейронка безыдейна. Такие игры приедятся через пару месяцев.
ну так мы ж предполагаем, что у нас есть хотя бы 1 человек, управляющий нейронкой, который пишет промт (уже не промт, уже харнес).
Как тут не вспомнить бессмертное
- Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы...
полагаете один человек сможет предложить столько замечательных идей? Ради любопытства гляньте на мобилки: там куча игр и все друг на друга похожи, только скинчики меняются. Будет также.
ну так делают то не потому, что идей нет (их ж люди делают да?), а потому что "это лучше продается" или "это проще сделать"
вообще "идея" в воздухе ничего сама по себе не стоит
однако я считаю, будет благо для всех, есть процесс создания ААА-игр станет более доступным. А не как сейчас. Юбики не могут родить уже годами ни фаркрай, ни хост рекон. Хотя казалось бы. Но нет.
А ГТА делают с перерывам. Сколько лет то? больше 10-и? Чего они там делают. Ну неужто полируют сюжет (в 4-й был 2 утырка, в 5-йо 3, теперь снова 2). Наверно нет, наверно чертовы движки очень плохо сделаны
Пусть Кирилл сам сделают игру про корованы. В целом сейчас "простенько" но сделать уже можно вайбкодя.
На счёт ГТА интересное замечание. Сейчас все упарываются в графику, так что понятно, что они делают.
Я чуть про другое. Возьмём к примеру ГТА. Пусть его прохождение будет условных 10 часов. Зачем Вам игра раз в 5 часов? Не нужно. Казалось бы, можно выпускать игру раз в 10 часов и радоваться, но такая концепция уже есть: онлайн игры. В них играют долго, кончено, но и они приедаются.
С другой стороны, оказывается, что есть люди, у которых в стиме куча игр, которые они покупали, но не играли ни разу. Т.е. проблем с тем, во чтобы поиграть нет.
И это всё я к тому, что проблемы у игровой индустрии вовсе не связаны со скоростью написания кода.
не совсем понял, что значит "игра раз в 5 часов", но тако рода игры это часов на 50. или даже 100
А онлайн-игры это ж игры не с новым контентом, это соревновательные игры, аля батлфилд. ей богу, меня на месяц хватило бегать по одинаковым картам (пусть их там даже и 10)
"Т.е. проблем с тем, во чтобы поиграть нет. "
не соглашусь, в целом вроде бы да, но нет такого с перламутровыми пуговицами. Вот если нет фаркрая, во что играть? "во что угодно", ну мне не надо "во что угодно", я хочу аутировать в хост рекон или фаркрай. И эти китайские юбисофты (или корейские) "кримсон десерт" мне не подходят
или х-ком. Закончились. Выходил немало похожих, но оно другое
купили, но не играли - дешевые игры купленные на распродаже. У меня тоже что-то подобное есть, в коллекции (типа самых первых х-комов, я играл 100 лет назад в пиратку. сейчас переигрывать особо смысла нет)
не совсем понял, что значит "игра раз в 5 часов", но тако рода игры это часов на 50. или даже 100
Я ж написал, условно. Я не знаю, сколько времени сейчас считается нормально проходить игру. Пусть будет 100 часов. Тогда нет смысла выпускать такие игры чаще, раз в 50.
А онлайн-игры это ж игры не с новым контентом, это соревновательные игры, аля батлфилд. ей богу, меня на месяц хватило бегать по одинаковым картам
Я больше ориентировался на какую-нибудь вовку, там вроде не так много соревновательного момента. Впрочем, вы верно заметили, что оно довольно быстро приедается.
я хочу аутировать в хост рекон или фаркрай
...
или х-ком. Закончились
Давайте я так скажу: За это время индустрия могла бы родить и икс-ком, и фаркрай, и много чего ещё хорошего. Ресурсы на это точно есть: если бы создатели провалившихся игр делали что-то из указанного, то так и было. Причины, по которым такие игры не делают, опять же, лежат в другой плоскости.
Профита нет в основном когда нет доступа или средств на Claude Code 4.8. Или доступ уже есть а сдвига в мышлении и опыта еще нет.
А так профит великолепен. В нашем проекте за месяц уволили 10 человек. Я добил за месяц модуль, на котором надеялся еще жить год другой и теперь не уверен что вообще буду делать и буду ли. Интерес заказчиков к этим результатам и доработкам все ниже. И так далее.
Кто сказал, что волшебная палочка которая есть у всех сделает всех богаче в мире где все игры идут с нулевой суммой?
Вот правда что, код - это прокладка между ИИ и результатом выполнения кода. Код не нужон!
Хотел вставить свои пять копеек про здравый смысл, но какой к черту смысл, если мы ИИ запрягаем, чтобы кода было много и быстро. Если за ИИ еще и вдумчиво ревьюить, то человекочасы сожрут всю выгоду. Так что переходим на одноразовые проекты и гори они огнем после сдачи в экплуатацию.
А нам точно нужны code agents?
Название не соответствует содержанию. Тема агентов не затронута. Агент - это надстройка над моделью. Агент это генератор промежуточных промптов и менеджер промежуточных результатов. Агенту поступает задание в общем виде, он разбивает его на подзадания.
На 2026 год большинство акторов IT-мира по-прежнему недооценивают уровень когнитивной нагрузки.
Понятие “когнитивная нагрузка” не раскрыто.
LLM генерирует код быстро. Его надо прочитать, понять, его надо снова поправить, снова прочитать, понять, снова поправить. Никто и не задумывается, а может ли вообще мозг работать в таком темпе.
Так и запишем: “Человек - слабое звено. Он мешает реализовать потенциал LLM.”
А нам точно нужны человеки?
И да, всегда остается вопрос - Если результат неудовлетворительный, то что надо менять - модель или промпт-инженера? Или вообще отказаться от LLM. Для решения таких вопросов у руководства должны быть соответствующие навыки и опыт. Понятно что этого пока у них нет.
Так вот, вопрос: а где тонны продуктов? Когда уже каждый разработчик станет сам себе предпринимателем?
Реальные продукты произведенные с помощью LLM - это правильный индикатор. Пора бы уже создать глобальный интернет-ресурс, на котором будут отражаться успехи LLM-а, и его вклад в прогресс цивилизации.
LLM как продукт пока сам еще не завершен. LLM сейчас в процессе альфа-бета-тестирования. Пользователи тестируют продукт, за свои же деньги. Разработчики LLM допиливают продукт как могут. Разработчик LLM не дает никаких гарантий, не описывает четко пользовательские свойства продукта, не несет ответственности за последствия. Использование на свой страх и риск.
Собесы мб попроще станут с этим засильем ИИ без всяких заучиваний того, что в рбаоте не пригодится. Ну правда и зпшка упадет
Грустно конечно с одной стороны, неплохая эпоха была, но она заканчивается. Что еще мир нам грядущий принесет
Опенсорс начинает реагировать, Godot запретит приём ai--generated изменений =)
The number of open PRs has become a meme in the community.
Да. Просто согласен с каждым пунктом. Инструмент полезный, но вошел в обиход слишком быстро и сверху вниз, а не наоборот. В итоге бесконечные ПРы, в которых никто включая автора не может понять, почему они такие бесконечные. Неконтролируемое разрастание кодовой базы. В какой-то момент само понятие "человека, ответственного с за кусок кода" становится бессмысленным. Понятно, почему это произошло. Понятно, что бизнес действительно получает некоторое ускорение разработки, скорее всего в долг, тк весь этот новый код еще не раз выстрелит в ногу в будущем. Непонятно, как выплывать. Т.е. на текущий момент просто сказать "нет, я принципиально использую LLM только в задачах вида Х (самых тривиальных), а в остальном пишу код руками" - это примерно как признаться, что считаешь на счетах. И при том все на нижних уровнях видят все проблемы сгенерированного кода, а толку. Транслировать это куда-то - карьерное самоубийство. Остается только надеяться, что в какой-то момент маятник качнется обратно и система вновь найдет стабильное состояние, инженерам опять разрешат самим выбирать инструменты для работы.
Понимаю, о чём вы. Сейчас бизнес видит красивый и быстрый результат, но почти не видит цену ошибок, поддержки и переработок, которые могут проявиться позже. Поэтому давление на команды растёт, а аргументы про архитектуру, безопасность и масштабирование сложно перевести в понятные менеджменту сроки и деньги.
Но я не думаю, что это повод пытаться сохранить ручную разработку в прежнем виде. LLM всё равно будут забирать всё большую часть работы, вплоть до полной замены написания кода человеком. Вопрос скорее в том, как пройти этот переход без хаоса. Нужны процессы, тестирование и контроль результата, пока модели ещё не умеют надёжно закрывать весь цикл сами.
Со временем и сами модели, и инструменты вокруг них станут лучше. Тогда разработка будет строиться уже не вокруг ручного написания кода, а вокруг постановки задач, проверки результата и управления продуктом.
Я смотрю на это с другой стороны, как человек, который внедряет ИИ-инструменты в разработку. Согласен, что нельзя принимать красивый результат модели за доказательство эффективности. Нужны ограничения, проверка качества и понятная ответственность за итоговый код.
При этом часть описанных рисков можно снизить не отказом от ИИ, а нормальным процессом работы: разбивать задачи, делать ревью, писать тесты, следить за размером изменений и понимать архитектуру (но не конкретно код). В таком подходе ИИ не заменяет разработчика (пока), но может заметно ускорить работу.
У меня был похожий опыт внедрения. Если интересно, могу поделиться ссылкой на статью в Песочнице.
Слишком много мыслей...
Моё вступление в техлида почти совпало с этой "ИИ-революцией", а именно с появлением агентского режима и субагентов. Мы прошли путь от "ИИ это просто подсказки через чат бот" до сети агентов, которые могут работать сразу в нескольких проектах, делать ревью и закрывать большую часть обычного цикла разработки.
На техдолге это дало огромный эффект. Мы разгребли то, до чего раньше руки не доходили вообще никогда, а заодно привели в порядок CI, тестирование и документацию. Без агентов на это ушли бы месяцы работы одного-двух разработчиков, да и еще нужен был бы кто это все проверяет.
Вот здесь я думаю можно именно сказать что мы реально заменили разработчиков на агентов, но тех долг это специфическая область, требования ясны и многие годами обсуждают, что и как нужно сделать. Дальше пришло время обычных задач.
И мы упёрлись ровно в то, о чём написано в статье ( https://jellyfish.co/2026-state-of-engineering-management/): человеческое внимание. Требования всё равно нужно анализировать, результат - ревьюить, а изменения - проверять на реальных системах. В статье конечно все гораздо шире и про стоимость и про другие проблемы. Но мое понимание как раз через лимиты надзора (supervision\human attention)
Пять агентов - это не x5 к скорости. По ощущениям, скорее x1.5-2, а иногда и меньше. Чем больше агентов запускаешь, тем больше времени нужно на их контроль. Уже сейчас на Team Premium - Sonnet и Opus могут генерировать столько кода, что невозможно одному отревьюрить.
В итоге основная ценность для нас оказалась не в том, чтобы просто быстрее пилить фичи, а в качестве, тестируемости и прогнозируемости. Плюс выяснилось, что бизнес тоже не может бесконечно быстро готовить требования и принимать изменения.
То есть после разбора основного техдолга мы вышли на плато: скорость теперь ограничивается не только разработкой, но и требованиями, ревью и человеческим вниманием. Вообщем без всякой большой революции в процессе.
Но я бы точно не советовал быть в стане отрицальщиков, которые ждут, что вот-вот всё рухнет и "кожаные" снова будут спокойно рубить капусту. Нет, мир уже меняется. И если хочется дальше рубить капусту, придётся тоже меняться и подстраиваться.
Отрицать прогресс довольно глупо. Лично меня он вывел на новый уровень понимания разработки и самого процесса. Возможность в любой момент проверить свою теорию, не тратя на это недели работы разработчиков, даёт огромный опыт, это как раньше приходилось строить воздушные замки и просчитывать их в уме, то сейчас спокойно можно строить настоящие. Даже если завтра агенты каким-то образом помрут, этот опыт у меня уже никто не заберёт.
Жаль только, что некоторые люди, особенно в менеджменте, воспринимают это не как усиление разработчиков, а как их замену. Удачи им.
Кому-то ок такой код и документация и разгребание техдолга. Я это вижу вживую на проектах в реальном времени и я вообще не воодушевлён качеством. Всё обложено спеками, сплошь "сделай хорошо" в каждой папочке и для доков и для кода, далее таски закрыты, дока полна, какие-то модули переписаны, окры и кипиаи в небеса... Но по факту, я начал читать эту доку и это просто гребаный слоп. Это невозможно читать без слёз, ни черта непонятно, она больше запутывает, чем что-то объясняет и рассказывает. Я скептически отношусь ко всему. И к доке и к тестам и к коду. Особенно к тестам. Тем более, предыдущий год с test driven AI development показал это наглядно. Когда тесты есть, а ни черта не работает. Я считаю, что всё это максимально важно и в нормальном проекте должно всё вычитываться и пропускаться через себя. Но для каких-то маленьких проектов, пет проектов вполне ок наговнокодить, да. Может и повезёт.
Вы как раз подтверждаете то, о чём я и написал. Мне кажется, когда видят комментарий о пользе агентов, сразу думают что это фанат вайбкодинга.
в нормальном проекте должно всё вычитываться и пропускаться через себя
Именно так. Неважно, сколько кода, тестов и документации нагенерировал агент - всё это должен понять и отревьюрить разработчик.
Поэтому для обычных бизнес-задач мы, например, ограничили использование автономных агентов: у нас просто нет возможности качественно ревьюрить такой объём кода. А мержить без человеческого ревью или заменять его ревью другим ИИ - это действительно путь в никуда.
Мой тезис не в том, что можно бесконтрольно генерировать слоп, а в том, что инструмент полезен, пока он усиливает разработчика, а не подменяет его ответственность.
На документацию мне пришлось потратить много времени, потому что авто генерация лишь база, а дальше приходилось долго править. Но это не сравнить с рукописным написанием.
И с тестами такая же проблема, если их не ревьюрить это просто бесполезный набор кейсов
А нам точно нужны code agents?