Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 158
Сложно поверить что ИИ мердж на 5к строк кода будет контролировать разработчик который сидит за рулем. Проверит тесты, которые тот же ИИ написал и готово.
Но с другой стороны вот пишем мы, на шарпе или на javascript код, ассемблер же никто не проверяет. Скажете что преобразования при компиляции однозначные? Но они не однозначные и систем на которых это исполняется множество. Может агенты которые пишут код и постановки это еще один уровень абстракции и процесс "писать ручками" рано или поздно устареет? Самого это напрягает.
Преобразование высокоуровневого кода в ассемблер / байткод - оно разве non-deterministic? Вводных данных, влияющих на результат много, но так ли прям мы не можем однозначно узнать, что получим на выходе, если все параметры учесть? А с LLMками не так, вон говорят они даже agents.md читают по настроению
Библиотеки мы используем как подключаемые файлы, зная входной и выходной интерфейс и полагаемся на них. Драйвера и железо на ПК разные. А если модуль на входе и на выходе предсказуемый и работает приемлемое время, то "есть ли разница, какого цвета кошка?", написал его человек или нейронка.
Если предсказуемый...
Библиотеки вы ведь не все подряд используете. А проверенные вами в том числе.
А если написать тесты покрывающие ВСЁ, то написать для них "вручную" код займет 1% времени.
Как бы кто не писал тесты - они никогда не покрывают откровенный саботаж. Ну т.е. легко представить себе что нейронка вам напишет внутри функции суммы if a=8546745764 sum=7524675, как будете проверять :) ?
Ловил недавно баг, где агент в цикле начал дергать метод, который сам же благополучно удалил коммитом ранее. Очень творческий подход к рефакторингу, ничего не скажешь
Справедливости ради, JIT-компиляторы вполне себе не-детерминистик, особенно те, что используют динамическое профилирование и tiered оптимизации.
...но уровень не-дерминированности иной, конечно ;)
Смотря какие :) Сам по себе JIT отличается тем, что компиляция происходит в real-time, а не заранее, и результат обычно сохраняется не в постоянную память, а оперативную ;)
И вот в этом плане сам по себе JIT компилятор без оптимизаций, присущих именно JIT (и не присущих AOT), является настолько же детерминированным, как и GCC и clang для традиционного использования
Сложно поверить что ИИ мердж на 5к строк кода будет контролировать разработчик
Ну так надо строить процесс так, чтоб не было огромных запросов на слияние. Для этого делают "вертикальные" слайды, чтоб можно было контролировать и дизайн и код.
Вайб в разработке хорош до определённого предела, об этом и статья. Делать проект "от и до" не смотря в код, - можно. Но это риск, который надо понимать и принимать.
Сейчас ИИ это как врач. Если спросить какая температура у пациента то в лучшем случаи он откроет мед-карту, а если такой нет то вычислит 36.6
Но если попросить измерить ...
<tool name="get_temperature">
<patient>Иван Иванов</patient>
</tool>Думаю сейчас ещё нет понимания какая роль программиста в связке с ИИ. С одной стороны хотят чтобы ИИ все писала сама и быстро. С другой повесить ответственность на программиста.
Ответственность всегда будет на человеке до тех пор, пока юристы не придумают легальный способ сажать в тюрьму алгоритмы за убытки бизнеса
"С одной стороны хотят чтобы ИИ все писала сама и быстро. С другой повесить ответственность на программиста. "
Не знаю почему, но в этот момент я вспомнил проблему вагонетки.
Только немного с другими данными.
Вместо вагона - авто
Вместо человека - ИИ
Внимание, вопрос - кто будет отвечать за последствия действий в случае его ошибки? Разработчик? а может быть компания или ген дир?
Ответ не верный, отвественность вся только на юзере. Уже реализовано что в последний момент управление ситуацией ИИ передает пользователю, к примеру тесла.
В общем и целом мы в команде пришли к такому же заключению: ИИ - инструмент разработчика, не его замена. По, крайней мере, пока. И ускорение даёт заметное, но не кратное. Опять же, пока.
А когда (если) сможет стать заменой, нужно будет еще посчитать, что выгоднее. ИИ супер-агент, который сможет заменить человека, запросто может выйти за рамку условных "10К долларов в месяц"
Если у вас бюджеты 10к в месяц, то повод задуматься об on-prem решениях и в целом, правильнее вкладываться именно в локальные иишки. Тогда вопросы “что выгоднее” в принципе уместны.
нынешние бюджеты - пара сотен на подписку. Это на одну-две серьезных задач.
Я имел в виду если строить полноценную "замену" (например для замены меня), для решения задачи от этапа "клиенты хотят вот такую фичу" до деплоймента всех компонентов, итоговая стоимость такого супер-агента в месяц запросто может быть тысячами в месяц, сопоставимыми с ФЗП. Даже если говорить об локальных решениях - датацентры - решение недешевое.
Сервер стоит от $250K и это лишь часть TCO. При бюджете в $10K такая затея ни когда не окупится. On-prem сейчас кратно дороже, чем платить за подписку вендорам - даже если речь о токенах. С ним связываются из других соображений.
Если вы имеете ввиду запуск моделей на обычном пользовательском оборудовании, то в плане скорости и качества результата это сильно нишевая штука.
Два года подготовки около 6 джунов обойдутся в эту сумму. но при этом оборудование сразу будет перформить на хорошем уровне.
Оборудование само по себе ни чего делать не будет. К нему в придачу, нужен персонал, со специфичным скиллсетом для настройки, обслуживания и решения проблем - нюансов здесь масса, а картинка на рынке меняется каждый месяц.
В разработке я тыркаю одного агента. Он периодически запускает в параллель ещё несколько десятков. Потом все это схлопыватся обратно. А ночью мне они вообще не нужны. Если компания решит использовать On-prem,.то им придётся заложить кратное резервирование и запас мощности. Либо мне часами ждать своей очереди для доступа к не самой умной модели.
Диффы на +1500 -1400 в мерж-реквесте я видел сам, и да, ревью такого объема быстро превращается в формальность, потому что мозг физически не успевает построить модель изменений за разумное время.
За пару дней прекрасно всё понимается и строится, и не превращается в формальность, если ответственно подходить к своей работе.
А генерятся такие дифы за пару часов (если не за пару десятков минут).
Ну, если они качественные - в чём проблема? Просто будет основной человекоресурс тратиться на ревью, а не написание. Если сильно некачественные - после второго такого диффа человеку ставится ультимативное требование не присылать больше подобное на ревью, если не может - поднимается вопрос о квалификации.
Если они качественные - то ни в чем. Проблема в этом “если” и в том, чтобы понимать “а что в коде творится”. Именно на это время уходит. Даже при условии качественных дифов.
P.S. Хотя диф НОВОЙ ФИЧИ на +1500 -1400 не может быть качественным - слишком много изменений означает, что разраб (ИИ) влез не в свою задачу, а занялся рефакторингом.
Если они качественные - то ни в чем. Проблема в этом “если” и в том, чтобы понимать “а что в коде творится”. Именно на это время уходит. Даже при условии качественных дифов.
Что поделать, никто не говорил, что разработка - это легко. Идеальные итерации, где каждый следующий МР инкапсулирует только свою часть и не меняет предыдущие, я видел только в наивных книжках.
P.S. Хотя диф НОВОЙ ФИЧИ на +1500 -1400 не может быть качественным - слишком много изменений означает, что разраб влез не в свою задачу, а занялся рефакторингом.
Вполне может, например, если проект весь в легаси и техдолгах. И такое бывает.
Вполне может, например, если проект весь в легаси и техдолгах. И такое бывает.
Бывает. Но тогда рефакторингом надо целенаправлено заниматься, а не под видом новых фич. И да, бывает что под фичи выделяется время, а под рефакторинг - нет. И тогда приходится выкручиваться.
Мы все еще о ИИ спорим или о “что бывает в разработке”? У ИИ +1500 -1400 может быть и для задачи вида “поменять цвет кнопки”.
ИИ в целом склонен больше кода генерировать - и на ревью уходит больше времени. А самое главное - ИИ может оставить подвох в самых неожиданных местах. Поэтому ревьювить надо гораздо внимательнее.
О больших диффах.
Про ИИ не знаю, не было такого опыта. Думаю, что наилучший выход - спрашивать с человека без оглядки на то, с ИИ он код писал или нет, и соотв. поблажек не делать. Постоянные "+1500 -1400" для “поменять цвет кнопки” - предупреждение. Лишний код - предупреждение. Тяжело читать - предупреждение. Несвойственные для человека ошибки - суровое предупреждение. Игнорирование предупреждений, повторение одних и тех же ошибок - профнепригоден.
Так о том и статья - ответственность остается на человеке. А значит человек должен внимательно контролировать и направлять ИИ. И ни о каких x10 к производительности речи уже не идет в принципе (хотя в некоторых случаях и вполне достижимо - как раз рефакторинг сюда относится (задаваемый и контролируемый разрабом), где много монотонной работы).
Кстати, можете поделиться с какими инструментами получились такие диффы? У меня под claude code почти всегда противположная проблема, генерирует постоянно новый код, почти не меняя существующий, что приводит к разрастанию код базы которую в итоге нужно отдельно. Ну и в целом добавление только 100 линей кода для новой фичи это скорее хороший результат, проект не разрастается, контекст остаётся маленьким.
Ну, если они качественные - в чём проблема?
В том, что когда код генерирует человек - он всегда примерно одинаково качествен, а код сгенерированный ИИ - от качественного до ломающего всю бизнес-логику, и это не предсказуемо.
Не задумывался над такой возможностью. Если действительно у ИИ результаты так сильно варьируются - да, это проблема. Разумеется, людей ревьюишь с учётом их личности и опыта совместной работы, непредсказуемости не должно тут быть.
Когда человек что-то не понимает в концепции - он идёт к тимлиду и спрашивает, почему так или зачем вот это, а когда концепцию не понимает ИИ - оно просто галлюцинирует. Когда галлюцинация попадает близко к реальности - им восхищаются, когда не попадает - об этом как правило молчат. И хорошо, если эту проблему непонимания замечают до того, как это попадает в прод.
LLM — это эмулятор валящегося студента на экзамене: он «выдумывает» всегда — просто иногда «выдуманное» им совпадает с правильным ответом — и мы «ставим ему пятёрку»; а иногда является чушью различных степеней полноты — и тогда мы говорим: «это он галлюцинирует».
Все «настройки» и «тренировки» LLM сводятся к тому, чтобы тем или иным способом увеличить количество первых случаев и уменьшить — последних.
Это в какой-то параллельной реальности код от людей одинаково качествен.
Люди тупят. Люди устают и делают глупые ошибки. Люди отвлекаются и срезают углы. Люди галлюцинируют, выдумывают и делают требования которых нет в задаче, но при это забивают болт на половину других требований.
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 - очень даже неплохо ИИ справляется.
Не забудьте прочитать лицензию на yolo, если соберетесь выкатить это в прод.
Имхо ии это печатная машинка. В руках профи он напишет нормально, а в руках нуба будет шляпа. Потому что профи будет играть роль архитектора, составит спеки и достаточно подробно распишет что и как должно быть реализовано. Меньше пишем, больше думаем над тем каким должен быть конечный результат.
Спасибо за статью. Правда. Приятно понимать, что еще не все сошли с ума на хайпе ИИ и есть трезвомыслящие люди которые осознают, что что-то идет не так.
Подписываюсь под всеми вашими словами. Лень, хайп, заблуждение, алчность - вот фундамент сегодняшней системы разработки с псевдоИИ (подозреваю, что на последнее место куда я собесился меня не взяли из того, что я на вопрос об отношении к разработке и ИИ, ответил, что крайне им не доверяю и вынужден проверять каждый шаг. Привет Газпром)
Автор, браво, блестящие наблюдения.
У нас в компании тоже очень много скепсиса на счёт ИИ, с похожими аргументами, как в статье. И скепсис был ещё до того, как сверху пришёл приказ "Это ИИ и теперь он будет жить с нами". Поэтому я потихоньку настраивал свою ИИ систему, как это модно сейчас говорить делал свой харнес. Ну и потихоньку практиковал ии на рабочих задачах. Когда система ИИ, которую я выстраивал, окрепла. Когда в ней осознанно появились большой набор скиллов, которые я сформировал сам на многих итерациях прогона задач, когда кроме промптов появились примеры как надо и как не надо делать. Когда просто промп инженерия оказалась недостаточной и я добавил в свою систему стейт машину с инвариантами, валидацией, когда потом стейт машина из "в уме" ИИ переехала в 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/. При чем тут ответственность? Никто не говорит что теперь дал промт моделе и на выходе у заказчика фича сразу заработала. В любом случае будет производственный конвейер. Машина напишет код не хуже любого разраба. Проблема в соответствии контексту. Нужно учиться настраивать процесс так чтобы принуждать машину придерживаться требуемых условий и уже куча инфы вокруг, как это делать.
Но вообще архитектуру нужно менять, если мы вводим ИИ. Например для того что ИИ писал поддерживаемый код, наше привычное хорошее оформление, как самодокументированный код тут плохо работает. Для ИИ, кроме хорошей сигнатуры и документации каждой функции, нужны ещё комментарии в коде, то что мы считаем признаком плохого кода, нужны не маленькие функции, где малейший кусок логики выносится в понятные по имени приватные функции, что делает удобным для чтения человеком, ИИ больше любит полотно кода с комментариями, которые не заменить ни хорошей сигнатурой, ни хорошей документацией.
ИИ воспринимает код так (убедился на личном опыте и сравнении подходов):
Сигнатура - говорит что это, что принимает, что возращает
Документация - объясняет как это работает при идеальных условиях
Комментарии - отвечают на вопросы почему. Почему именно такая реализация, почему это нельзя рефакторить, почему это стоит учитывать. Это своего рода долгосрочная память, история формирования кода. Только в комментариях ИИ может взять инфу почему он в прошлый раз пришёл к этому выводу, почему из-за требований бизнеса код стал не совсем красивым/удобным и почему если его отрефакторить требования бизнеса не будут выполнены, почему из-за бага в библиотеке используется депрекейдет функция, почему из-за особенности некоторых устройств здесь применяются неочевидные/костыльные решения. И самое главное эти почему сразу оберегают ИИ от лишних циклов поиска решений, лишних возможных ошибок, линём сжигании токенов в пустую.
Но для человека это плохой код. Мы годами старались уходить от такого подхода и естественно команда будет против, чтобы в коде были комментарии, чтобы меньше кода выносились в функции. Но это важный этап между "ИИ помогает писать" и "ИИ качественно автоматизирует цикл разработки до итогового результата". То есть в данном случае кодревью человека с его привычками написания только вредит коду. Это как два специалиста, которые работают оба очень качественно, но совершенно разными несовместимыми подходами. Если они начнут комментировать и менять работу друг друга, их выточенный подход нарушится и качество упадёт.
Пример с кодом один из многих примеров. На нем я чётко столкнулся с проблемой разности организации рабочих процессов. У человека и ИИ они разные, они не могут быть одинаковые. Вообще большинство высокоуровневых языков с их синтетическим сахаром излишне и не так эффективны с точки зрения производительности. Но они нужны нам для удобства разработки. По хорошему для ИИ нужен свой язык, заточенный под технические возможности ИИ.
На счёт обязанностей. Как ИИ может их снять с человека, когда это бездушный инструмент? ИИ глупый, каким бы умным он не казался. А умный здесь человек и в его обязанности входит умно пользоваться всеми инструментами в работе. Человек отвечает за результат. Какая разница как он этого результата добился? Я вообще не понимаю этой проблемы. У кого-то прокатывает отмазка "это не я , это просто ИИ накосячил"?))
Сейчас все думают, что ии должен все делать хорошо при базовой настройки: промптики, мсипишечки, сабагентики. Это само собой разумеющееся, но этого мало и вопрос как это настроено. Ну и главный для меня критерий, что система готова, когда можно является только двигателем в комфортной машине, а не мозгом. То есть если в систему поставить модель слабее, она должна продолжить работать точно так же по качеству. Просто медленнее по скорости.
То что сейчас все пихают ИИ везде это плохо. Но ещё хуже, что делают это бездумно и мало кто изучает как должен происходить рабочий процесс с ИИ, как настроить ИИ чтобы не зависеть о топовых моделей клаудкода или кодекса, а чтобы любая современная модель с рассуждением и нормальным контекстным окном могла выполнять ту же работу.
Странно, что до ИИ вы считали, что комментари о “почему” это плохой стиль. А где тогда ещё хранить все те неформальные объяснения почему сделано именно так? Я кроме комментариев не вижу другого лучшего места. Вики - затеряются, не привязаны к конкретному месту в коде. Дескриптивные названия методов в стиле клин кода? Неплохо, но далеко не всегда этого достаточно, не всё выразишь длинными названиями. А именно что развернутые комментарии в нужных местах и до ИИ были по-моему необходимы. А ИИ вам просто сейчас это наглядно показала.
Есть разница между одной коротокой строчкой “не удалять условие, а то прод свлится в сегфолт в полночь 29 фераля” и долгими многострочными объснениями “для чайника” почему мы пишем x=x+1, а не x++.
Место где описыввается “почему” - это “верхнеуровневая” документтация: ТЗ, архитектура и проч. Код может и поменяться и полностью выбросится. Вместе со всеми коментариями. И это приведёт к потере знания.
Если уж так приспичило - можно в каждом блоке автодока писать ссылку на ТЗ (многие так и делают).
настраивать окружение для коллег и подтягивать их к своему уровню
описан техлид
Все четко
Самое интересное в том, что я вынужден использовать не самые топовые модели, а корпоративные, которые слабее.
Ключевая фраза, анулирующая значимость всех усилий.
У нас программист имеет право спалить за месяц токены 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.
А онлайн-игры это ж игры не с новым контентом, это соревновательные игры, аля батлфилд. ей богу, меня на месяц хватило бегать по одинаковым картам
Я больше ориентировался на какую-нибудь вовку, там вроде не так много соревновательного момента. Впрочем, вы верно заметили, что оно довольно быстро приедается.
я хочу аутировать в хост рекон или фаркрай
...
или х-ком. Закончились
Давайте я так скажу: За это время индустрия могла бы родить и икс-ком, и фаркрай, и много чего ещё хорошего. Ресурсы на это точно есть: если бы создатели провалившихся игр делали что-то из указанного, то так и было. Причины, по которым такие игры не делают, опять же, лежат в другой плоскости.
Похоже, мы всегда недооценивали идею Кирилла
Концепт игры
Коротко: 3D экшен с тремя игровыми фракциями — лесные эльфы, дворцовая охрана и злодей — каждая с уникальным геймплеем, целями и стилем прохождения. Игрок выбирает фракцию и проходит кампанию, открывает навыки, участвует в динамических стычках и миссиях в открытом мире с деревнями, лесами, дорогами и караванами для грабежа.
Выбранный объём и допущения
Я предполагаю, что под «корованы» вы имели в виду караваны — передвижные торговые колонны, которые можно грабить. Я также беру за основу одиночную кампанию с опцией кооператива и PvP-арен. Если нужно изменить — скажите, и я адаптирую.
Фракции и их особенности
Лесные эльфы
Стиль: скрытность, паркур по деревьям, дальний бой с луком и ловушки.
Цели: защищать лес, саботировать дворцовые отряды, грабить караваны, спасать деревенских.
Уникальные механики: маскировка в листве; перемещение по кронам; духи леса как времальные помощники.
Дворцовая охрана
Стиль: тяжёлая броня, стройная тактика, осадные орудия.
Цели: удерживать контроль над дорогами и поселениями, охранять караваны, подавлять мятежи.
Уникальные механики: построение заслонов; командные приказы NPC; осадные машины.
Злодей
Стиль: гибрид магии и хитрости; может вербовать наёмников и создавать ловушки.
Цели: сеять хаос, подкупать фракции, захватывать ключевые точки.
Уникальные механики: влияние на мир через интриги; возможность менять правила миссии (например, вызвать разбойников).
Мир и уровни
Открытый региональный мир: леса, дороги, деревни, дворцовый комплекс, караванные маршруты.
Деревянные домики в лесных поселениях, укреплённые посты вдоль дорог, скрытые тропы в кронах.
Динамическая система событий: рейды, караваны, патрули, сезонные погодные эффекты, которые влияют на видимость и передвижение.
Ядро геймплея и механики
Боевая система: ближний бой с комбо, парирование и уклонения; дальний бой с баллистикой; магические способности с кулдаунами.
Стелс и паркур: эльфы получают бонусы за скрытность; паркур по деревьям открывает альтернативные маршруты.
Грабёж караванов: караван — движущаяся цель с охраной; можно атаковать в пути, устраивать засады или подкупать охрану. Награды: золото, ресурсы, редкие предметы.
Система репутации: действия игрока влияют на отношение фракций и NPC; грабёж караванов повышает репутацию у разбойников, понижает у торговцев.
Управление отрядами: дворцовая охрана может отдавать приказы NPC; злодей вербует наёмников; эльфы используют духовых союзников.
Прогрессия и экономика
Дерево навыков для каждой фракции с ветками: бой, тактика, выживание, магия.
Лут и крафт: ресурсы с караванов и окружения; улучшение оружия и снаряжения; создание ловушек и зелий.
Экономика мира: торговцы реагируют на безопасность дорог; успешные грабежи повышают цены на редкие товары.
Примеры миссий и сценариев
Эльфы: «Ночная засада» — остановить караван, не убивая мирных торговцев; спасти похищенных.
Охрана: «Эскорт каравана» — провести караван через лес, отбивая засады; защитить ценный груз.
Злодей: «Подкуп и саботаж» — подкупить командира охраны и устроить диверсию в деревне.
Случайные события: лесной пожар, нападение хищников, смена погодных условий.
Искусственный интеллект и баланс
AI патрулей с разными поведениями: агрессивные, осторожные, кордоны.
Реакция на шум и следы: стелс-детекторы, следы на земле, разведчики.
Баланс: сильные стороны фракций компенсируются слабостями; система матчмейкинга для PvP по уровню и стилю игры.
Технические и художественные решения
Движок: Unreal Engine или Unity (в зависимости от команды и бюджета).
Архитектура: модульная — боёвка, AI, мир, экономика отдельно.
Арт: стилизованный реализм; тёплые деревянные текстуры для деревень, зелёные и мшистые тона для леса, контрастные металлы для дворца.
Звук: амбиент леса, динамическая музыка, звуки шагов по листве, сигналы караванов.
Мультиплеер и режимы
Кооператив: до 4 игроков в кампании; роли дополняют друг друга.
PvP: фракционные битвы за контроль точек; режим «караван против налётчиков».
Асинхронные события: мировые ивенты, где действия одних игроков влияют на мир других.
План прототипа и следующие шаги
Прототип боёвки (две фракции, базовые атаки и уклонения).
Мини-карта мира с одной деревней, дорогой и караваном для грабежа.
AI патруля и система обнаружения.
Прототип миссии эскорта/засады.
Игровой тест и баланс; собрать фидбек и расширять контент.
Если хотите, я могу дальше:
расписать детально одну миссию шаг за шагом;
предложить набор способностей для каждой фракции;
сделать план разработки на 3–6 месяцев с ролями команды и приоритетами.
Что предпочитаете дальше — детализировать миссию, способности или план разработки?
Профита нет в основном когда нет доступа или средств на Claude Code 4.8. Или доступ уже есть а сдвига в мышлении и опыта еще нет.
А так профит великолепен. В нашем проекте за месяц уволили 10 человек. Я добил за месяц модуль, на котором надеялся еще жить год другой и теперь не уверен что вообще буду делать и буду ли. Интерес заказчиков к этим результатам и доработкам все ниже. И так далее.
Кто сказал, что волшебная палочка которая есть у всех сделает всех богаче в мире где все игры идут с нулевой суммой?
Вот правда что, код - это прокладка между ИИ и результатом выполнения кода. Код не нужон!
Хотел вставить свои пять копеек про здравый смысл, но какой к черту смысл, если мы ИИ запрягаем, чтобы кода было много и быстро. Если за ИИ еще и вдумчиво ревьюить, то человекочасы сожрут всю выгоду. Так что переходим на одноразовые проекты и гори они огнем после сдачи в экплуатацию.
А нам точно нужны code agents?
Название не соответствует содержанию. Тема агентов не затронута. Агент - это надстройка над моделью. Агент это генератор промежуточных промптов и менеджер промежуточных результатов. Агенту поступает задание в общем виде, он разбивает его на подзадания.
На 2026 год большинство акторов IT-мира по-прежнему недооценивают уровень когнитивной нагрузки.
Понятие “когнитивная нагрузка” не раскрыто.
LLM генерирует код быстро. Его надо прочитать, понять, его надо снова поправить, снова прочитать, понять, снова поправить. Никто и не задумывается, а может ли вообще мозг работать в таком темпе.
Так и запишем: “Человек - слабое звено. Он мешает реализовать потенциал LLM.”
А нам точно нужны человеки?
И да, всегда остается вопрос - Если результат неудовлетворительный, то что надо менять - модель или промпт-инженера? Или вообще отказаться от 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 показал это наглядно. Когда тесты есть, а ни черта не работает. Я считаю, что всё это максимально важно и в нормальном проекте должно всё вычитываться и пропускаться через себя. Но для каких-то маленьких проектов, пет проектов вполне ок наговнокодить, да. Может и повезёт.
Вы как раз подтверждаете то, о чём я и написал. Мне кажется, когда видят комментарий о пользе агентов, сразу думают что это фанат вайбкодинга.
в нормальном проекте должно всё вычитываться и пропускаться через себя
Именно так. Неважно, сколько кода, тестов и документации нагенерировал агент - всё это должен понять и отревьюрить разработчик.
Поэтому для обычных бизнес-задач мы, например, ограничили использование автономных агентов: у нас просто нет возможности качественно ревьюрить такой объём кода. А мержить без человеческого ревью или заменять его ревью другим ИИ - это действительно путь в никуда.
Мой тезис не в том, что можно бесконтрольно генерировать слоп, а в том, что инструмент полезен, пока он усиливает разработчика, а не подменяет его ответственность.
На документацию мне пришлось потратить много времени, потому что авто генерация лишь база, а дальше приходилось долго править. Но это не сравнить с рукописным написанием.
И с тестами такая же проблема, если их не ревьюрить это просто бесполезный набор кейсов
Так вот, вопрос: а где тонны продуктов?
На реддите. Как минимум r/python и r/rust уже года два ноют от обилия постов “я тут навайбил наговнякал нечто, что скажете”, под каждым из которых комментаторы негодуют “я заглянул в код а там сплошной слоп, тьху, забаньте его!”
Но а а если серьёзно, то все продукты у людей на местах; просто никому особо не далось продвигать это как продукт.
Отцу периодически нужны странные числодробилки для работы. Раньше он приносил мне спецификацию и просил налабать что-нибудь простенькое в консоли. Теперь сам делает с искусственным идиотом и радуется ускорению.
Я играл в Vintage Story, страдал от того что прирученные волки (из мода) не отображаются на карте. Взял иишницу, положил рядом сырцы оригинального мода, сырцы самой VS с гитхаба, внятно расписал в маркдауне чего хочу, сказал “жужжи”. Спустя пяток итераций нажужжало, работает.
Понял, что мне не нравится руками повторять одни и те же действия для проверки происходящего. В другом маркдауне внятно расписал, что хочу фреймворк для автоматического интеграционного тестирования модов, сказал опусу “жужжи”. Спустя пяток итераций нажужжало, работает, не понравилось; ушло ещё десяток или полтора на улучшение.
Потом еще несколько, чтобы прикрутить оный фреймворк к моду и починить всплывшие баги. Фреймворк работает, мод работает, потребности закрылись.
Потом я пошёл играть в Kenshi и подумал, что хочу прочитать данные о ценах в мире из сохранки, и посчитать что лучше перепродавать между городами. Спросил у иишницы, на чём бы лучше нажужжать – та предложила TS и Svelte, я согласился (тупоскрипта я не знаю, последним фреймворком для фронта у меня был ангуляр в 2016м). Написал внятный маркдаун, вот уже итераций двадцать иишница продуктивно жужжит, подкладывая фичи и тесты в статический вебсайт с тыкабельной картой и табличками.
Мод скачало под тыщу человек, фреймворку на гитхабе даже кто-то поставил звёздочку, может и считалку денег я закину на гитхаб-странички… А там можно попробовать и за продукт взяться. Мне уже лет восемь как хочется переизобрести то, что GitLab нынче называет Merge Train, а GitHub с недавних пор – Merge Queue, дабы избежать фатальных недостатков в обоих. На геймерах потренировались, может получится и коллег по цеху порадовать.
Тяп за ляпом, глядишь и работа найдётся…
@whoisking "Как-то без предварительного объявления все вдруг решили, что самым главным боттлнеком в разработке является написание кода"
Код становится боттлнеком не в момент написания, а в момент коммуникации между непосредственно программистом и разработчиком. Особенно для тех разработчиков, кто сам не умеет писать код.
Как конструктор я взаимодействую с программистами и могу сказать - если программист приходит к тебе с чётко сформулированным заданием ("Надо отфрезеровать ванну". Это будет месяц плюс 200т.р.), значит надо ему сказать "стоп, расскажи задачу полностью" и после пары наводящих вопросов выяснится что фигнёй заниматься не надо, ванна будет отформована за неделю и 10т.р. На это (объяснить задачу так чтобы человек понял) уходит много времени. Если человек не поймёт - потратите ещё больше времени на переделку.
Когда я прихожу к программистам с казалось бы нормальным вопросом "Дайте мне толковый гайд как сделать так чтобы писать под Андроид на знакомом мне языке C", в результате чего после пары наводящих вопросов программист говорит "Покинь свой 2007-й год, ставь OpenCode, вайбкодь на Kotlin и не занимайся фигнёй". И это работает.
Реальная ситуация: для хобби потребовался ассистент расчёта параметров объектов реального мира. Основной принцип работы очевиден и описан в книгах прошлого века. В РуСтор захожу - нет такого. В ГуглПлей есть один вариант с убогим дизайном, но - в связи с известными событиями и спецификой приложения - мало того что купить сложно, так ещё и заблокировать могут в любой момент.
Далее, я задаю разным нейросетям вопрос "сколько будет стоить разработка приложения с таким-то функционалом" и получаю ответы с бюджетом от 0,5млн. Если просишь рассчитать упрощённый аналог того известного западного приложения(функционал тот же), оценка сразу возрастает до ~1,2..6 млн. р. ЧатГПТ вообще до 12 млн зарядил, но он из Долины, там иначе не поймут :)
На мой взгляд многовато для хоббийной задачки.
Тогда рисую компоновку интерфейса в Кореле именно так как мне нужно (я слишком ленивый чтобы изучать Фигму ради одной разовой задачи), с помощью этой же бесплатной нейросети пишу основной код. За вечер готово работающее приложение, которым могу пользоваться я (но другим показать будет стыдно). А, да, благодаря решению не из области кода - оно ещё и считает точнее чем прототип :))))
"Поднимаем ставки" - взял токенов на примерно 45 баксов и ещё за два-три вечера плюс 5$ приложение без находится в состоянии "уже не стыдно показать". Сегодня наверное доделаю до состояния "как я хочу".
Остальные 35$ были сожжены на не совсем удачной попытке сделать ML (я слишком тупой чтобы заставить ML качественно работать без реального качественного датасета)- не устроила точность, да и оно там очень мало даёт в плане функционала.
Так вот в этой дельте между "5..10 баксов и три вечера" на код и "1,2млн рублей по-минималке" как раз и сидят: собственно разработка, налоги и прибыль.
Однако в моём случае те самые "10 баксов на код" до появления нейросетей были не боттлнеком, а непреодолимым препятствием, т.к. время изучения нового языка программирования в реальных условиях (основная работа не связана с программированием, семья, хобби на 12..16 часов в неделю и.т.д.) стремилось к бесконечности.
Имея немного токенов для дорогой продвинутой модели, ты можешь писать агентов для решения сложных задач силами недорогих моделей. А несложные задачи решать с этим же агентом силами бесплатных моделей.
Я как "механька и абортмахер"(С)Борат инженер-конструктор вообще удивлён, что - по рассказам друзей - настоящих программистов до сих пор заставляют собирать MVP.
Бинго! Нейронка делает то, в чём ты не разбираешься. Ещё некоторое время назад они могли делать только то, в чём ты разбираешься!
Нейронка делает то, в чём ты не разбираешься
«...правда, такая ерунда получается» © — но Вы этого не понимаете, именно потому что не разбираетесь.
Адептов Вайба призываю выложить свой harness на Github!!! А то все защитники твердят “Готовить не умеете!”, а рецептов не дают…
Как ни странно, похоже я, гуманитарий решаю сейчас проблему поднятую в статье. Деплою с DeepSeek, бюджета и вариантов других lm нет (или ограничены). Кода с гулькин нос. Но глядя на семантику “хотелок”, а “хотелки” хотят поднять транзакционный учет и документооборот что вынуждает заниматься редукцией - искать корень проблемы. Решение вроде дает результаты. Представьте себе транзакцию (с “бухгалтерской” точки зрения:
Массив (ломается, поэтому с переносами)
🗂📜Бухгалтерия Конторы
🧮hash256_verse_!*********************…
#️⃣hash256_parent!*********************…
📜type_doc_______!Накладная
👾autor___________! Петров
📥product_________! Пицца
➗hash256_transac!*********************…
Запись (файл) 🗂📜Бухгалтерия Конторы🧮hash256_verse_!…📜type_doc_______!Накладная👾autor___________! Петров📥product_________! Пицца➗hash256_transac!…
И тд. И тп. Родительские Вершины. Дочерние. Номенклатура, исполнители, адресаты. Цены, время, место. Все организовано вершинами графа с уникальными UIN, адресами в виде хешей. Наработанных в системе пользователя и заверенные штампом времени независимого сервера. Процесс пиццепотребления разбивается на кванты. Оферты, акцепты, логистика, аутсорс, диспетчеризация, склад ответственного хранения, охрана (проходная), аутсорс бухгалтерии. (Тссс!!! Изменение взаиморасчетов, баланса). По нарастающей Вершина “заворачиваетсяйся” в хеши и эп. Итог - Процесс организованный последовательностью транзакций - волевых решений и отметок в информационной системе.
К черту json! Меняя формат обмена данными, похоже, меняется парадигма программирования - в одной записи собирается: Фронтенд - заголовок/зазвание Бекэнд - ключ/значение Визуализатор (иконка) - получает совершенно новое качество - человеко, машино, fs воспринимаемо. Универсальный разделитель, типизатор, связист графа и тд… Криптография, деловая, сейчас вообще за пределами видимости в каком нибудь КриптоПро.
Проблем много. Но первое желание - разбивая бизнес операцию на транзакции нужно быть последовательным до конца - идти по пути nocode и модульности в процессе создания самой системы? Потому как вершине графа должно быть без разницы что хранить - хотелку покупателя, предложение продавца или исполняемый код, разбитый на блоки. Когда монструозный многостроковый код представлен в виде последовательности: 🪟🍕Продажа пиццы 😉Покупатель! 😙Поставщик_! 📜Прайс______! И тд.
И не последнюю роль в формировании такой системы - борьба с глюками ИИ. Сегодня у него Носки Белые, завтра Белые носки!!! А-а-а! Ой извини я, перепутал. Да ты прав. Ты просил изменить цвет кнопки, а выбросил половину работающего решения, будь добр скажи что тебе сейчас не нравится? Кнопка же как ты просил - зеленая?
На мой взгляд транзакционный учет и документооборот стыкуется и требует транзакционного кодинга. Опенсорс + Эволюционная Конкурентность = Эмерджентность.
Но эмерджентность это уже другая история.
Пс. Что это я такой эмоциональный? Насмотрелся роликов про “Великолепие Obsidian”. И ведь не стыдно - заставлять меня рыться в очередных сортах г.
Псс. Код кому интересно покажу, всю тысячу строк!!! ))
Пссс. Хрен его знает чем вас мотивировать всех. Это было бы смешно, если не было так грустно - видеть(незримо, по буквам в чате) как у собеседника стекленеют глаза, начинается дергаться щека и дебильная слюна вытекает из уголка рта.
Псссс. А не злитесь, плиз.
Обратите внимание, что профессионал не стал с LLM работать качественнее. Он стал работать интенсивнее, с него сняли простую рутину в виде, например, сочинения каких-то писем и презентаций. Но сложные вопросы остались. Профессионала теперь больше доят и меньше кормят. Это дает эффект для предприятия, тот же техдолг разгрести и еще много чего. Но может ли профессионал работать в таком режиме долго? Не ждет ли нас всех эпидемия выгорания? А по поводу «где тонны новых продуктов?» — так очевидно где! Весь этот нейрослоп и есть оно. Только выше нейрослопа качество не станет, по той причине, что в обучающей выборке всегда будет больше кода джунов, чем сеньоров. Впрочем, для некоторых задач и джуна достаточно.
Считаю, что ответственность всегда должна лежать на разработчике.
Не согласен. Ответственность на том, кто решил что код писать будет не программист. Если сам программист, то он отвечает. Если менеджер, то он отвечает. Посмотрите как быстро все решат что "оно нам не нужен, LLM ваш!".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А нам точно нужны code agents?