Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 287
Вот почему я больше не читаю код
Да, хреново когда не знал, да еще и забыл...
Вот живой пример из недавнего. Чувак с гордостью представил свою разработку, над которой он, по его словам, работал больше года. Только репозиторий со всей историей был создан буквально на днях. Старательно вычистил все демаскирующие Клода вещи, но кода в мешке не утаишь.
А потом народ не поленился и накопал под сотню серьезнейших проблем в этом коде слопе.
Беда в том, что таких уslёпков будет все больше. Разумеется, проблема не в ИИ и не в Клоде. Это замечательный инструмент, если уметь им пользоваться. Проблема в людях, которые, вайбкодь@не_читай и херак-херак-в-продакшн, притом что ни в том ни в том не разбираются от слова совсем.
таких уslёпков будет все больше
не в защиту вайбкода, но ради справедливости ради.
В мире существуют миллионы приложений созданных методом копипаста со Stackoverflow и публичных репозиториев (написанных человеком без участия ИИ) Неоптимизированные библиотеки, фреймворки ради фреймворков, издевательское потребление вычислительных ресурсов. Программисты это оправдывали тем, что их время слишком дорогое, чтобы писать код идеально, потому что улучшать можно бесконечно. Вычислительные мощности растут, а мы концентрируемся на фишках и архитектуре. Мы программисты, а не машинистки. Но почему-то ни для кого это не является проблемой.
Cколько серверов настроено скриптами скачанных с github написанные неизвестно кем и запущенных от root . И это опять ни для кого не является проблемой.
Так что ИИ хрючево не является проблемой. По крайней мере я не слышу возмущения от Paramount, что ИИ заберёт у них работу.
Вот живой пример из недавнего
Не факт, что некто умнее/опытнее не разнесёт ваш код написанный руками, выложив вы его в открытый доступ. Неизвестны ни квалификация автора ни квалификация проверяющего. Но такой код-ревью определенно пойдёт на пользу.
В мире существуют миллионы приложений созданных методом копипаста со Stackoverflow и публичных репозиториев
Порог входа даже в такой копипасте заключается в том, что во многих случаях "скопипасченый" код не работает и его нужно немного причесать, либо заглянуть в ветку комментариев и посмотреть там прочие предложенные варианты, которые подойдут именно вам.
+ надо знать куда вставлять и как. Сейчас нету даже такого сдерживающего фактора, и к этим "миллионам" еще "миллиард" на подходе))
Не факт, что некто умнее/опытнее не разнесёт ваш код написанный руками
так речь не только в "разносе кода"
почти все вещатели успешного успеха - либо пустое репо имеют, либо просто созданное "15 минут назад". Побеждают в международных ИИ хакатонах, о которых кроме одной группы в ВК на 200 человек никто не знает ну и так далее... Список их ИТ-регалий бесконечен. А по факту, насмотрелись на "больших дядек" в ИТ, и захотели стать такими же, и теперь каждый стал архитектором и надулся как ИИндюк)
Сейчас нету даже такого сдерживающего фактора, и к этим "миллионам" еще "миллиард" на подходе
Сдерживающий фактор чего? No/Low-Code платформы как-то обрушили ИТ-отрасль? Как и с ИИ, домохозяйки и региональные ИП вкатились и для своих потребностей использовали без приобретения всяких Битрикс за тонны (зачастую неоправданных) денег или колупания в Joomla. Пока никто вайбкодеров на работу в битехи не берёт. Бигтехи сами внедряют ИИ под присмотром труЪ Senior software architect. Если вам придётся конкурировать с вайбкодером на рынке труда, ну что ж... когда-то и лошадь была транспортом, а сейчас развлечение на выходные.
Список их ИТ-регалий бесконечен. А по факту, насмотрелись на "больших дядек"
Проблема-то в чём? В том, что при появлении новой ниши в неё стараются пролезть все кому не лень? Или то, что у вас об этой нише иное представление.
No/Low-Code платформы как-то обрушили ИТ-отрасль?
Они не давали и близко тех возможностей, которые предоставляют сейчас ИИ, особенно в сфере инфоцыганства.
Теперь даже пьяный Васян с соской пивчанского за гаражами знает, что он сеньон фуллстак архитектор. Который пишет техническую статью на профильном ресурсе
Пока никто вайбкодеров на работу в битехи не берёт. Бигтехи сами внедряют ИИ под присмотром труЪ Senior software architect.
Эти бигтехи с вами в одной комнате?
Проблема-то в чём?
Для меня проблема в том, что я не хочу за это платить. а по итогу вынужден. За пафосный соевый банкет для вайбкодеров, сейчас кастомеры - покупатели техники заплатят
Они не давали и близко тех возможностей
Вы уж определитесь: или "ИИ это скам и пузырь" или "ИИ даёт такие возможности, которых не было раньше." Докажите свою незаменимость делом.
Я как сетевой инженер не ощущаю на себе влияние ИИ. Я несколько недель пытался уговорить ИИ настроить мне порт по инструкции вендора или в GNS3 лабе имея доступ к сети настроить мне хотя бы OSPF связность. ИИ пока не может выполнять мою работу. Хотя казалось бы сетевым RFC уже почти 60 лет.
Эти бигтехи с вами в одной комнате?
вы можете это загуглить, а не прикидываться шлангом
я не хочу за это платить.
проект "импортозамещение" работает на полную катушку. Покупайте оборудование отечественного производства, в России нет AI пузыря.
в России нет AI пузыря.
А доступное российское железо есть, да еще и в рознице?
А то я помню на Хабре Репку пиарили по цене х2,5 от топовых конфигов RPi (которые, тащем-то, тоже недешевые). Ну то есть молодцы, конечно, что сделали, и в документацию вложились и т.п., но идея (изначальная) у RPi "недорого для обучения", а Репка получилась дорого и непонятно для кого.
"ИИ это скам и пузырь" или "ИИ даёт такие возможности, которых не было раньше."
ИИ - это инструмент. Шумиха и визг вокруг ИИ - это скам и пузырь.
ИИ дает возможности: специалистам работать чуть комфортнее, инфоцыганам - инфоцыганировать. Ну либо жить в розовом мире и выдавать желаемое за действительное.
вы можете это загуглить, а не прикидываться шлангом
гуглеж очень быстро выводит на маркетинговый пердеж, ничем не подкрепленный - принять просто на веру?
проект "импортозамещение" работает на полную катушку.
На западе, в США, в Китае тоже импортозамещение? посмотрите цены в евро\долларах\юанях.
А еще 8Гб оперативы в мейнстрим ноутбуках в 2026 году возвращается, видимо, как пакет санкций против России, чтоб мы тут параллельным импортом не ввозили 16-32 гиговые модели=)
Я как сетевой инженер не ощущаю на себе влияние ИИ
я на себе тоже его не ощущаю, кода в моей жизни не так много, в основном скрипты и с теми LLMки справляются просто ужасно. Выдумывают методы и классы, которых не существует.
с MDX запросами в BI аналитике тоже самое. Но, справедливости ради, помогли самостоятельно этот самый MDX освоить, и основные концепции.
ИИ даёт такие возможности, которых не было раньше
— скамить и пузырить!
Буквально вчера задачка была, элементарная ошибка на сайте, человек не постеснялся даже скинуть мне что ему чатжипити об этом говорит, но починить не может, а проблема куда глубже, там рказалось какая то кастомная панель управления, которая криво php настроила, не хватала модулей и версию менять надо было, я залез и на 4 часа разбирался как панель умтроена. Так что все верно в целом вы говорите. Особо не помогло клиенту
Не факт, что некто умнее/опытнее не разнесёт ваш код написанный руками, выложив вы его в открытый доступ.
Когда этот код android-приложения, который никто никуда не выкладывает, реверснут, то может оказаться, что там много интересных моментов, позволяющих делать что-то, что автор не предполагал и не хотел бы чтобы делали.
Причём, для анализа как раз соответствующую нейронку применят.
И тогда радость автора, что Клод умеет по логам фиксить свои ошибки, "немного поубавится".
>Но почему-то ни для кого это не является проблемой
Еще как является, только сделать с этом ничего нельзя. Но это не значит что об этой проблеме надо перестать говорить. Как и о проблеме написания говнокода с помощью ИИ.
ушлепок пока здесь только один с повышенным ЧСВ
Некоторые уже начинают запрещать контрибьютить ии-код. В репозитории fastapi чуваки прямо в сontributing.md прописали, что будут банить авторов, код, PR или комменты которых похожи на слоп.
А потом народ не поленился и накопал под сотню серьезнейших проблем в этом
кодеслопе.
Я недавно наконец понял, почему в старых боевичках сервера Пентагона взламывают командой ping. Я-то думал — они в компах ни бум-бум, а оказывается — они просто в нейробудущее зрели.
Сначала "я не пишу код".
Потом "я больше не читаю код".
Дальше будет "я не смотрю, как этот код работает".
И в финале "мне больше не платят зарплату".
Не, на а чё? Вполне естественный процесс...
Сегодня ты не читаешь код, а завтра твоя программа, сгенерённая ИИ для постов картинок ИИ с описаниями от ИИ постит в Фейсбук детскую порнографию с прекрасным описанием, всё как ты и просил, и вдруг ты слышишь требовательный стук в дверь. Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Иногда читать может быть нужно, а иногда достаточно хорошо настроенного CI/CD, линтеров, тестов, чекеров безопасности и других инструментов. Чем больше автоматизации для проверки кода, тем меньше потребность его читать. А задачи от пользователей могут быть почти сразу быть направлены в разработку используя AI агентов.
да, линтер конечно спасет от cp. а тесты, штош их тоже АИ писал
Бывает код вида if (time == n) { db.dropAll() }
Я конечно утрирую, но когда llm создавала граничную ситуацию там, где её нет (и не покроешь тестами) - я видел своими глазами. Не будешь же функцию с одз в long реально гонять на всех long-aх в тестах.
Тесты как трусы: прикрывают, но не защищают.
Надо сделать невалидное состояние невозможным.
А можно пример, что там LLM накосячил?
А можно пример, что там LLM накосячил?
Доступа к коду этому у меня уже нет. Но упрощенно выглядело так - есть код, обрабатывающий диапазоны значений и функции для каждого из диапазонов. Условно от 1 до 10 использовать f1(x), от 11 до 20 использовать f2(x) и от 20 до 30 f3(x))
Надо было добавить пару диапазонов, LLM сделала из перекрывающимся в части диапазона (от 1 до 10 f1(x) и от 8 до 22 f2(x) ), но при этом внутрь функции f2 запихнула проверку if (x == 10 || x == 21) return;
Как итог - тесты проходили, на граничных значениях все хорошо, в центре диапазона всё хорошо, а взять значение немного у края - то сумма считается уже неправильно.
В жизни конечно код был чуть сложнее - отвечал за подсчет коммиссий. На ревью кстати было не так просто увидеть т.к. код ветвистый а изолированные функции выглядели просто и корректно. Ошибку заметили только благодаря тому, что условие проверки границ внутри функции вызывало подозрение.
сумма считается уже неправильно.
Пороть, пороть и пороть за такое.
Ясно.
Но лучше было на уровне архитектуры такое запретить через pattern matching
enum Range {
R1_10(u8), // 1..=10
R11_20(u8), // 11..=20
R21_30(u8), // 21..=30
}
impl Range {
fn new(x: u8) -> Option<Self> {
match x {
1..=10 => Some(Self::R1_10(x)),
11..=20 => Some(Self::R11_20(x)),
21..=30 => Some(Self::R21_30(x)),
_ => None,
}
}
fn process(&self) -> i32 {
match self {
Self::R1_10(x) => f1(*x),
Self::R11_20(x) => f2(*x),
Self::R21_30(x) => f3(*x),
}
}
}В утрированном примере с конечным тех заданием сразу - да)
На деле проверки были не рядом а между ними были дополнительные шаги, которые могли привести к попаданию в другой диапазон, и нет - написать вот так красиво в принципе не получилось бы т.к. для вычисления точного значения нужно было лезть во внешние сервисы, а лезть в них всегда было слишком дорого по производительности, и понятность того, нужно это делать или нет была частью постпроцессинга.
Можно было бы заменить это на рекурсивной вызов функции с проверкой диапазонов, но тогда туда помимо прочего надо было бы накинуть вагон аргументов, вычисляемых на первом этапе, чтобы не делать это повторно, и при этом все они были бы необязательные - даже не знаю лучше бы стало или ещё хуже)
проверки были не рядом
В разных сервисах?
Я намекаю что профессор лопух, но аппаратура при нём LLM накосячил, но так и человек мог сделать после того как исходный разработчик ушел вместе с сакральными знаниями. Надо запретить такое вообще.
"так и человек мог сделать" "Надо запретить такое вообще"
AI: Так точно! Ваше приказание выполнено! Человек запрешён!
Человек так накосячить бы смог только злонамеренно (ну или прямо зелёный, который пишет не думая по принципу "вставлю код не осознанно, а в надежде что соберётся"), т.к. llm добавил исключительную ситуацию (проверку граничного значения диапазона) туда, где этой проверки никак быть не должно было. Это было нарушением и принципа изоляции слоёв бизнес логики, и нарушение принципа единственной ответственности для функции, и отлично от аналогичных решений в коде рядом.
Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Ахахахаха. Супер! :)
Пробовали когда-то через ту же нано банану генерить какое-либо порно? Как успехи?
ну по сути, даже если бы автор писал программу руками, то она могла бы запостить это
Один нюанс: все это работает, пока антропик и прочие демпигуют, работают в минус и прожигают шальное бабло инвесторов. На чужом горбу в рай. Впрочем, ничего нового.
Но есть и обратная сторона - триллион на AI уже сожжен (буквально, в гигаватт-часах), чипы распаяны, ДЦ уже построены, модели уже обучены.
5% нынешней окупаемости отрасли смогут покрыть только инференс, даже в случае банкроства и распродажи ДЦ с долговых аукционов.
Т.е. в каждый момент времени можно ожидать, что уже достигнугнутый моделями уровень ниже не упадет даже с наступлением полномасштабного кризиса отрасли (на таком масштабе пузыря он неизбежно совпадет с общим финансовым кризисом).
Следствие - те, кого модели могут оставить без работы уже сейчас, они оставят без работы и в случае кризиса ИИ отрасли. Банкроство ИИ стартапов не возродит профессию переводчика текстов, например.
Исторические аналогии - банкроство железных дорог, как стартапов 19 века, не остановило железнодорожное сообщение. Построенными дорогами все равно пользовались. За исключением совсем экстремальных случаев ЖД веток в никуда.
Речь про цену данного удовольствия. Все эти пророки "новой эры" любят повторять, что "как раньше уже не будет". Хорошо, не будет. Но вся бравада строится исключительно на том, что теперь всегда будет так, как сейчас. То есть антропик теперь во веки вечные будет толкать им свой товар по 100 баксов в месяц. А если по 1000 баксов? А по 5000? Уже за 1000 баксов болтовни будет на пару порядков меньше. Какой-то вселенский закон запрещает такой исход событий? Всегда на рынке будет такая же анархия и конкуренция как сейчас? Это тоже каким-то законом предопределено?
Смотрите хотя бы опыт Яндекс такси. Сначала тоже кипятком ссали от низких цен.
Мне кажется, вы привели Я.Т. как пример "не в ту сторону".
ЯТ замечательно заменил бомбил и тогда и сейчас. Вы вообще часто на дороге руку поднимаете? Да, сказочно дешевый период закончился, начался просто дешевый. Он по прежнему дешевый, дешевле, чем бомбила.
А еще, мне кажется, AI отлично офшорится. Никто не обязывает иметь ИИшный дата-центр через квартал - там все равно скорости медленные. Можно даже правдоподобно вообразить AI-датацентры за северным полярным кругом - там проще с охлаждением и проще ставить АЭС.
Никто не обязывает иметь ИИшный дата-центр через квартал - там все равно скорости медленные. Можно даже правдоподобно вообразить AI-датацентры за северным полярным кругом - там проще с охлаждением и проще ставить АЭС.
А потом решаешь зохавать какой-нибудь, например, полуостров — и обаньки...
На полуострове нет термальных источников. Надо взять Исландию в аренду. Там незамерзающая, но прохладная вода со всех сторон, и термальные источники. "Халявная", круглогодично-ровная генерация.
Не нужно ничего брать в аренду, просто нужно быть Президентом одной очень мощной страны, и тогда объявляешь, что вокруг нужной тебе земли крутятся эсминцы и подлодки других стран, а поэтому эта земля должна стать твоей. И все, никакой аренды.
В чем здесь логика, вопрос не ко мне, но судя по всему это работает 😂
начался просто дешевый
Мне нужно было из Северного в Южное бутово доехать - 600-800 рублей днем, 1200-1500 рублей в час ночи. Это 10 минут езды, 6 километров.
А бомбила прям ждал бы во дворе в час ночи чтобы отвести за триста?) В итоге просто бы пошёл ножками, но то что яндекс ауел - факт 🌚
бомбила как раз и увез меня за 500 во втором часу ночи:)
Может это был случайный проезжий, подхватил по пути? 🌚
Ну при таком раскладе, в чём тогда мотивация бомбилам идти в яндекс и платить им конские комиссии? Стой себе до двух часов ночи у соседского дома, авось пассажир сам да подойдёт. А вот что я наблюдаю каждый раз на жд вокзале нашего провинциального городка, так это подходишь к бомбилам и тебе заряжают ценник косарь за 15 минут поездку. Отходишь на 150 метров, вызываешь яндекс, и увозят за 350-400.
Может это был случайный проезжий, подхватил по пути?
не, это был яндексовский таксист, который мимо кассы повез)
На счет цен яндекса - у меня стоимость довезти мое тело из бара после закрытия метро, может доходить до 3.5 - 5к в 2 ночи за 40 минут езды.
Я конечно все понимаю, но это явно перебор. Я перестал ходить в бары, дешевле дома за компом сидеть)))
Ят монополист. Где вы видели чтобы в монополиях без контроля со стороны что-то было дешево?
Монополист ли? Он доминирует на рынке, это да. Примерно как AWS доминирует на рынке "серьезного" хостинга. Но он не может манипулировать рынком. Сфера заведомо высококонкурентная, кто угодно может завтра сесть в машину и поехать таксовать. И хоть эти потенциальные таксисты сидят на диване - они влияют на цены, не дают им подняться. Как только яндекс поднимет из до небес - я сам сяду в машину и поеду на конечную метро к последнему поезду.
Но сейчас - не делаю так, потому что нафиг мне это нужно, за такие копейки?
Как только яндекс поднимет из до небес - я сам сяду в машину и поеду на конечную метро к последнему поезду.
Времена бомбил давно прошли в Москве.
Они же не по календарю проходят. Времена счет прошли? Они прошли тем, что компьютеры удобнее и быстрее и дешевы. И компьютеры вечно конкурируют со счетами, даже если счет уже никто не производит, поэтому в каждом маленьком магазинчике чтобы посчитать сумму трех товаров стоит аппарат, который может полет спутника обсчитать.
Но если завтра по какой-то причине (монополия, санкции, катастрофа) компьютеры станут бесконечно дороги - время счет вернется. Именно невовзвращение старого - подтверждает, что новое лучше с учетом всех-всех факторов, включая цену.
Яндекс не поднял цены настолько, что бы маленькие таксопарки опять смогли зарабатывать. Антропик не поднимет настолько, что бы найм живого программиста, пишущего руками, стал бы рентабельным.
Но выжать максимум, подняв цены до 95% от цены программиста они конечно постараются в будущем. Итог будет зависеть от конкуренции с китайцами, в частности. Вам выше верно написали, инференс дешёвый, даже если ни один инвестор больше не даст ни рубля на обучение новых моделей, текущие модели можно продавать в плюс, поэтому они никуда не денутся.
И каждые 5% эффективности будут усугублять положение, а уж 5% там без сомнения есть где выжать (мое личное мнение - еще 100 раз по 5% точно возможно)
Антропик не поднимет настолько, что бы найм живого программиста, пишущего руками, стал бы рентабельным.
Я вообще-то на другой тезис отвечаю. Текущий modus operandi автора это "я код не читаю, иишка всё сама, если что - попрошу переписать". Так вот такой благодати будет тем меньше, чем ближе цена подписки к справедливой и рентабельной.
Отрицать удобство Я.Такси просто глупо
тут не так давно был всплеск статей (вроде и на хабре тоже было что-то) о том, что ии-ускорители выходят из строя быстрее, чем успевают окупиться, так что ДЦ сами по себе могут быть не сильно ликвидным активом.
А что *ять, если нет? (с)
Когда вышел первый iPhone -- брусок с полностью стеклянным экраном, тоже "здравый смысл" подсказывал, что на рынке телефонов ему делать нечего и Apple всё.
доведут со временем до нормальной готовности, сейчас просто потогонка и не успевают скорее всего железо отладить
Да пфф, зависимость от энергопотребления очень и очень нелинейная. Можно снизить энергопотребление процентов на 25% потеряв 5% производительности. А это сразу меньше температура и меньше деградация чипов.
Откуда информация про 5 процентов? И от чего эти 5 процентов? От бесплатных подписок? Платных? Подписок за 100-200 баксов? Enterprise подписок? API в токенах?
Выдумывают. По факту никто не знает размерностей тех же моделей антропик, их архитектуры, может их на карте десяток, условно. Информации о том, сколько зараьатывается с одной карты тоже нет, как собственно и инфы что за железо, только гадают. Я лично уверен в том что деньги зашибаются большие, и очень, именно поэтому всё и развивается для пользователей, и уж сложно поверить что зарабатывают 5%.
Они скорее зарабатывают этак минус 100 процентов. На каждые 10 баксов клиента они свои 10 сверху вкидывают. А с учетом инвестиций которые они собираются делать окупаемость им вообще никогда не светит.
Их доход оценивают от 5 до 7 миллиардов в год. А инвестиций они уже пообещали на 50 миллиардов. Даже максимально оптимистично это 7 лет дохода. Пусть с учетом возможного роста 3 года даже.
На практике это означает что пузырь совсем надут. Окупать расходы и инвестиции никто и не планирует.
Для сравнения весь Китай с миллиардом населения планирует в нейтросетки вложить 70 миллиардов. На все.
Я такие же расчеты в свое время про фейсбук слышал. Там тоже был пузырь, который никогда не окупить.
Покажете?
Ссылки на обсуждение 20 летней давности? Это шутка?
Фб был убыточен лет 5 подряд, насколько я помню. И имел сотни миллионов убытков.
Это конечно не Амазон, который был убыточен лет 10 и имел миллиардные убытки, но тоже неплохо.
Комментарии можете сами себе вообразить исходя из таких фин показателей.
Убыточен это не пузырь. Пузырь это когда тратят деньги которых нет на товар который не произведен и на основе этого раздувают оценки убыточного бизнеса до триллионов.
Не первый пузырь в истории. Всегда все одинаково.
Тоже самое писали про Фейсбук, ага. Пузырь, которые лопнет, а акция раздуты.
Так покажете?
Акции к реальному миру вообще отношения уже не имеют. По акциям Тесла дороже всего китайского автопрома, а вот покупают все равно китайские электрички.
Я именно про воздушные замки с контрактами ни на что и траты денег которых не существует. Фейсбук нормально рос, без такого.
Ссылки на обсуждение 20 летней давности? Это шутка?
Фейсбук нормально рос, без такого.
Из 2025 года такое легко писать. Как и то что биткоин нужно было покупать.
История Фейсбука известна. Включая все этапы и все финансирование. Это было интернет время.
Просто покажите ссылку где почитать кто надувал пузырь на Фейсбуке тогда.
1) в Китае совершенно другая стоимость лидов (в отличие от us) и конкуренция идёт только с китайскими моделями (по понятным причинам), которые ещё и дообучаются на дистиляции, странно эти цифры сравнивать в "лоб"
2) на каждого интересующего их клиента они могут тратить и тысячи баксов капитальных затрат в минус в годовом отчёте в данный момент просто на то чтобы лида завести и удержать, включая bottom-up интеграцию через бесплатные планы
На нужной дистанции (по приведенному вами календарю Майя - 7 лет) останутся только операционные затраты, которые могут вполне себе окупаться (если уже не окупаются в Max подписках) или апи
3) Вы предполагаете что оборудование они закупают в настолько больших масштабах, насколько возможно (просто чтобы им дали его купить)? Сколько у них его там по факту никому не известно, может и на все 7 лет вперёд (по календарю Майя)
4) задумывались вы об этом или нет, но антропик - это по сути б2б компания, можете погуглить, сколько зарабатывают сейчас б2б компании, у которых сравнимое с ними количество клиентов - Майкрософт, например
На практике означает что вы жонглируете несуществующей информацией, основанной на том, что вам кажется, что сущности которые уже зарабатывают миллиарды вдруг разучатся это делать
А этот клиент на которого потрачены тысячи и тысячи долларов возьмет и уйдет завтра. И ой.
Я знаю сколько Антропик получает от клиентов и знаю сколько они обещают потратить. Эти цифры просто из разных миров. Так бизнес не работает.
Или не уйдет. Не подскажете в случаем средний ретеншен их текущих таргетнвх клиентов? И кто их таргетные клиенты?
И можете в таком случае сказать, сколько конкретно стоит генерация каждого токена для каждой из моделей?
И на что конкретно тратятся деньги сейчас?
Для оценки хватает трат на порядки превышающих доходы. Причем на десятичный порядок.
Это точно лопнет. Вопрос только в сроках. Лопнет потому что столько денег нет. За генерацию нейрослопа люди никогда не будут платить столько чтобы отбить те траты которые запланированы.
Проблема в том, что вы не владеете информацией о денежных потоках, а также, возможно, не различаете операционные и капитальные затраты, и вам кажется, что в бизнесе такого размера капитальные затраты должны или могут окупаться в течение одного года (на этой дистанции и строятся отчёты о разницах прибыли / убыли)
Там все капитальные затраты должны отбиваться максимум лет за 5. Это среднее время жизни сервера которому надо быть на острие технологий. Иначе другие съедят, у кого сервера новее и вычисления дешевле.
Вам в общем никто не мешает верить что наконец то надули путь который не лопнет. Вся история против, но ладно.
Должны кому? Мне кажется вы за капитальные затраты считаете только закупку железа, когда по сути это просто одна из затрат при захвате доли рынка (и не факт, что самая большая)
Бизнесы такого размера разве что в безубыток выходят за этот срок
Вы говорите о всей истории, но в ней есть и амазон, и убер, и нетфликс, которые до первого прибыльного года шли 6-14 лет, и пока они что-то не лопнули
Сейчас ситуация больше похожа на убер, рынок постоянно растет, конца этого роста не видно, прибыль в моменте не приоритет
Да при чем тут прибыль.
Пузырь не про прибыль. Он про слова и раздувание пустого места. Ровно то что происходит последний год.
Если ты бы они нормально росли и нормально инвестировали то к убыткам вопросов нет. А они тратят свой десятилетний доход за одно обещание. И на это раздувают свою цену акций.
Дальше надо вовремя продаться по раздутой оценке или еще лучше IPO провести. И выскочить из этой истории с мешками денег.
У антропика нет акций, есть только оценка фондов, которые в них вложились
Помимо оценки у них растет и оборот, и база клиентов
Можете почитать про то как венчурные фонды работают, и за счёт чего их private equity идёт "возврат" денег -
За счёт стоимости актива, их никто фондам никогда из прибыли на инвест дистанции не возвращал (она может быть 5-15 лет)
Что такое "нормально" росли и инвестировали? Какой бизнес вообще растет быстрее антропика по кол-ву клиентов и ревеню, из не иишных? У них сейчас топовые модели
Назовем это оценка и доли. Какая разница?
Клиентов на 6 миллиардов дохода в год. Долгов наобещали на 50 миллиардов. Что-то не сходится.
Нормально это когда тратишь что-то сравнимое со своим размером. И когда оценка стоимости твоего бизнеса как-то совпадает с твоим оборотом. Почитайте что такое финансовый пузырь. Начать можно с тюльпанов.
Откуда у антропика долг в 50? Взять инвестиции - это не взять в долг, этот кеш дают не чтобы его вернули, а чтобы его сожгли,
Вы кстати в курсе, сколько у них денег сейчас на балансе? 5? 10? 40? Этот кеш вообще сожгли? Или у них ещё на несколько лет есть runway?
Они пообещали потратить 50. Может и не потратят конечно ,но это начало лопания пузыря будет. Когда тратишь чужие деньги это вроде и называется долг?
На балансе своих у них огромный минус. Одни долги. Я тоже могу взять в долг дофига и хвастать огромным счетом в банке.
Долгом называется то, что надо вернуть (зачастую в определенный срок)
Инвестиции такого формата никто никогда не возвращал кешом из прибыли,на них покупают долю в бизнесе
Их "возвращают" стоимостью актива (часть которого на эти инвестиции вообще-то купили, если что), так что их дают на то, чтобы их потратить для достижения какого-то kpi - обычно оборот или кол-во клиентов, буквально сжечь в рост, и то и другое у антропика кстати вроде как растет
если интересно можете погуглить про раунды инвестиций
Сможете показать их экскельки с фин потоками и минусом на балансе кстати?
Инвестиции точно так же надо возвращать. Инвесторы эти деньги не подарили а дали что потом взять больше.
Все как с долгом или вернул или банкрот. Фактическая разница минимальна. В контексте ломания пузыря разницы вообще нет.
Я уже пять раз показал. 5-7 миллиардов дохода, 50+ миллиардов расходов. Так бизнес не работает.
Инвестиции в данном случае это не долг, а покупка доли (и места в борде), их возврат в таком формате рассматривается только в виде роста стоимости этой доли
Не вижу, где они израсходовали 50 миллиардов, никакой информации об этом нет, как и нет информации о статьях этих расходов
Убер, да и многие другие миллиардные компании, каким-то образом так заработали, точно так же открыв абсолютно новый рынок
В контексте "когда пузырь лопнет" это не имеет значения. Те кто купили долю за миллиард в расчете что оно целиком стоит 100 миллиардов быстро обанкротят фирму которая начала стоить тот самый милиард целиком. Их цель потом продать свою долю за 10 миллиардов ,а не вот это вот все.
Вот же
Today, we are announcing a $50 billion investment in American computing infrastructure, building data centers with Fluidstack in Texas and New York, with more sites to come. These facilities are custom built for Anthropic with a focus on maximizing efficiency for our workloads, enabling continued research and development at the frontier.
https://www.anthropic.com/news/anthropic-invests-50-billion-in-american-ai-infrastructure
Чистые расходы. Которые надо отбить как-то.
Убер не тратил десяток готовых доходов на что-то разом. Он вообще довольно экономно развивался.
1) Это анонс, а не факт затрат (эти деньги ещё не потратили, и неизвестно когда их потратят до конца, по ссылке лишь написано, что первые ДЦ могут начать функционировать в 26 году), к тому же это капитальные затраты, а не операционные
2) неизвестно насколько с новыми ДЦ вырастет маржинальность или уменьшится стоимость r&d, может и в разы
Какие признаки лопания пузыря? AI компании растут как по обороту, так и по кол-ву клиентов, строят дц, которые должны уменьшать их операционные косты, модели становятся умнее, профессии потихоньку исчезают, все больше AI-стартапов-пользователей-моделей на венчурных деньгах и даже на бутстрепе растут и выходят в плюс (увеличивают ltv разработчиков моделей таким образом), кол-во реальных юзкейсов для генеративного AI с каждым днём увеличивается
Пока выглядит так, будто пузыря никакого и нет
Ну что есть. Годы там близкие, сойдет.
Маржинальность может меняться как угодно. У них всего 6 миллиардов дохода в год. 50 миллиардов отбить в принципе невозможно с такими доходами. Зато стоимость раздуть и побольше денег вынести самое оно.
Признаки? Все. Уже вообще все. Даже самые медленные уже заметили что пузырь надут. На Хабре статьи были.
Доходы могут быть. У доткомов тоже доходы были. Пузырь это не про доходы.
Хабр это прям авторитетный ресурс в вопросах бизнеса и финансов (нет)
У доткомов был трафик в минус, который работая с инвесторами не могли конвертировать в деньги, потому что то кол-во трафика в те времена могли монетизировать в плюс в основном серые и черные компании (адалт, нутра), с которыми нельзя было работать при поднятии белых денег
Помимо оценки у них растет и оборот
В этом треде всё сильнее и сильнее пахнет зайцем.
В том и проблема, что реальных цифр рентабельности нет, только спекуляции и додумки, но продукты у иишных компаний уже работают и фактически удаляют рабочие места пластами и заменяют на новые, на таком кол-ве реальных клиентов и юзкейсов сложнее не заработать, чем заработать (всегда можно скатиться до рекламы, госухи и военки)
Но ведь цифры есть. Жесткие минусы у всех. И даже идей нет как в плюс выходить. Классические планы к 2030 году. Ишак, падишах.
Deutsche Bank cited a forecast disclosed by OpenAI showing that, OpenAI's cumulative losses before achieving profitability could reach as high as $143 billion. OpenAI forecasts revenue of $345 billion between 2024 and 2029, but expenses for computing power are expected to reach as much as $488 billion. Furthermore, this projected $143 billion loss does not include OpenAI's recently announced $1.4 trillion commitment to data center investment.
143 миллиарда долларов убытка это вам не шутки. И это без обещанных расходов еще. С ними все вообще страшно становится.
Для сравнения вся прибыль Гугла это 100 миллиардов в год. А они полинтернета держат.
Не уверен, что вы прочитали то, что сами скинули
1) это projected losses, которые could reach as high as
Реальных данных в этом примерно 0
2) Это cumulative, то есть суммарный минус, за 5 лет в данном случае
3) нигде нет ни про операционную прибыль, ни про то, как капитальные расходы на постройки ДЦ, электростанций и ТД на нее повлияют
4) Про идеи это чистые спекуляции, учитывая что прямо недавно опенаи заявили о тесте рекламы - основной доход того же Гугла, тиктока, Фейсбука, твиттера, Пинтереста, и ещё много чего ещё
5) Это годовая прибыль Гугла, не за 5 лет. А оборот у Гугла какой?
Это убытки которые уже планируются. Вполне себе хороший показатель. Сколько денег надо взять откуда-то в ближайшие несколько лет.
Дц имеют свойство быстро устаревать. Тем более дц на видеокартах. Лет 5 и все. Не стоит считать расходы на них капитальными. Они примерно такие же операционные.
Продавая доллар по 90 центов можно получить любой доход. Буквально любой. Кому какое дело до него?
А вот про рекламу согласен. Это выход. Но это поляна Гугла и он ее так просто не отдаст. Рынок рекламы точно не вырастет на порядки, надо отнимать тот что есть. Я бы не был уверен что Гугл проиграет.
Амазон шел к "прибыли" много лет, но он был операционно прибыльным. Т.е. операционную прибыль тратили на рост, ре-инвестиции, и были по факту без чистой прибыли, но и без убытков.
А большинство этих ИИ стартапов тратят не заработанное, а чужое.
Амазон и после ipo не был прибыльным операционно
А антропик не в рост случаем вкладывается? Просто раздает деньги бедным африканцам, наверное
В этом также и вопрос, есть у них операционная прибыль на таргетных клиентах или нет, сейчас снаружи понять это невозможно из-за наличия огромных капитальных затрат, может так сложиться, что с подписок за 100-200 баксов она и имеется даже сейчас
Если предположить что те кто в них кладут деньги проводят хоть какой-то due deal (а они его проводят), то может и есть
А может и нет, но рынок настолько пустой что грех его не занимать, пока дают
Тут вот в цифрах написано как это выглядит.
https://fortune.com/2025/11/26/is-openai-profitable-forecast-data-center-200-billion-shortfall-hsbc/
В частности, пишут что для выхода OpenAI в прибыльность, его должны использовать 44% взрослого населения планеты.
Оно за пейволом
Но что-то мне кажется что там нет реальной цены токена, кол-ва денег которые они тратят на "получение пользователей" (включая бесплатные планы), разделение прибыли или маржинальности по планам / апи, ретеншена, и даже хотя бы предполагаемых доходов от рекламы на их трафике (который сравним с гуглом)
>Оно за пейволомСкорее кто-то его блокирует, статья доступна бесплатно. перед НГ читал бесплатно, перед написанием коммента проверил что статья доступна, а сейчас уже да, хотят денег.
Таких подробностей там нет, но пишут что до 2030 года прибыли не ожидается, и на сегодняшний день требуется доп. 200 млрд. инвестиций (к тому что уже найдено).
Это всё до появления нечётких или противоречивых требований, эдж кейсов и прочей грязи, после которой ваша сверкающая машинка быстро падает и делает громкий бум.
Только человек может выявить противоречия, сбалансировать решение, документировать для будущих изменений.
Приведенные в статье утилиты это редкое исключение когда можно делегировать LLM
Так просто уже существует опенсорс утилиты делающие то что нужно. Естественно их пересборка легко дается иИ
Совсем не обязательно, у меня AI агент на нечётки и противоречивых требованиях вопросы задаёт. Но конечно если человек сам разбирается со своими противоречиями и определяет какое соотношение между крайностями дихотомий для него допустимо, то разработка идёт на порядки эффективнее.
Я не волшебник, я только учусь, но такой подход не будет работать с чем то длиннее ТЗ в полстраницы. Ни с кремниевой нейронкой, ни с белковой. Я склонен считать, что ЛЛМки в целом уже достигли уровня человека в разработке, а вместе с этим начали воспроизводить все человеческие косяки.
Без внятного ТЗ результат ХЗ
Что вы Клод попросите реализовать, то он и реализует. Как попросите так и сделает. Из самых лучших побужденией. Откуда ей знать какой будет у вашего проекта трафик? Фрилансеру из Бангладеш хотя бы бюджет известен.
Теория разбитых окон в разработке
ЛЛМка честно пытается воспроизвести что-то похожее на то, что у вас было. При этом если было до этого 10-летнее легаси, то она по умолчанию его и выдаст. Если вы хотите, чтобы было написано иначе сформулируйте правила соответствующим образом.
Ваши договорённости с вашим джуном известны только вам и вашему джуну.
Новый джун, что нейросетевой, что мясной их знать не будет. Тем более новый джун с новым наставником. Просите его это корректно документировать и вносить в соответствующие правила. Контекст проекта не должен состоять из одного кода.
Приказ понял? Повтори как понял!
Просите нейронку объяснять как работает имеющийся код, проверяйте её объяснения, записывайте и импортируйте в AGENTS.md наиболее важные вещи. Проверяйте её объяснения, сверяйте её структуры и API.
Делегирование бывает разных уровней
Освоив работу с LLM-кой последовательно, начинайте делегировать задачи более высокоуровневым агентам. При этом вы сможете меньше проверять код из под LLM-ки, например код внутри методов (Да, бл..дь! Его всё ещё надо было поглядывать), и чуть больше успевать. Но придётся лучше формализовать уже порядок работы с нейро-джунами со стороны нейро-сениоров.
То что кто-то ошибается в 10% случае, когда вы ошибаетесь в 3%, не делает его хуже
В такой ситации значительно важнее, что его 10% и ваши 3% могут не пересекаться.
Скрытый текст
Есть универсальный алгоритм решения задач и проблем, любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов, когда для каждой микро задачи будет готово решение можно провести обратно - композицию. Даже сегодня любой ИИ агент запросто способен разбить любое ТЗ на задачи, причём так, чтобы максимизировать параллелизм в разработке, то есть планировать задачи таким образом, чтобы множество других агентов или людей могли работать над задачами параллельно, не пересекаясь по функционалу, что минимизирует конфликты.
Таким образом благодаря этому алгоритму можно добиться того, что любое ограничение контекста больше не является проблемой. А учитывая с какой скоростью ИИ агенты закрывают задачи, сколько бы потом не было багов - это можно компенсировать добавлением тестов после каждого бага, чтобы он никогда не повторялся и в итоге система будет стремиться к полному покрытию тестами и легко может разрабатываться используя в том числе исключительно AI агентов.
можно декомпозировать, можно повторять, можно написать, будет готово решение, агент способен, можно добиться, можно компенсировать, может разрабатываться.
вот бы прочитать статью о том, как все это декомпозировано, повторено, написано, решено, добыто, компенсировано и разработано?
Я это сделал при работе над своим agentic framework, решая тяжелую задачу в одиночку, которую пара команд не осилила за два последних года из-за плохой организации работы как раз вот в этой области: планирование, декомпозиция, гапсы и проч.
чтобы не быть голословным
Планирую за этот месяц закончить эту задачу. Без агента было бы непосильно, просто из-за количества времени на этап планирования, которое менджмент просто не одобрил бы. Но для того, чтобы его так использовать, я два месяца разрабатывал как раз фреймворк, просто plain usage какой угодно "дорогой" модели/агента это просто токены жечь.
Не уверен, что хочу писать об этом целую статью, поскольку проект фрейморка в стадии PoC, хочу убедиться, еще на паре "тяжелых" бизнес-задач, что это работает (мультиагентность и оркестрация в том числе), до промышленного внедрения еще полгода или больше. Просто поверьте, что подход разбития ТЗ на задачи агентом работает, хорошо грумит гапсы между легаси ТЗ и тем, что уже ушло дальше (бизнес-фичи поменяли codebase), хорошо раскладывает горизонтальные и вертикальные имплементации. Выявляет параллелизацию. Умеет оркестрировать.
Я не профи в использовании agentic swe, возможно, можно уйти и дальше. В чатиках пишут про бесконечные циклы решения задач от первого промпта/ТЗ до деплоя. Может, и врут, но заманчиво.
любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов
Один из ключевых тезисов теории систем и системного анализа говорит о том, что свойства системы не равны сумме свойств всех её частей.
Проводя декомпозицию задачи по уровням, вы теряете контекст применения, из-за чего, конечная подзадача, на глубине нескольких подуровней, может не отражать или отражать неверно/избыточно первоначальную часть задачи.
Проблемы которые будут:
Часто - избыточная алгоритмическая сложность (квадратичный/экспоненциальный алгоритм вместо линейного например)
Редко - избыточное переусложнение кода в результате расширения одз (нужна функция решающая частные случаи, при сегментации задачи остаётся подзадача решающая все случаи)
А если делать это с помощью llm - появляется ещё одна вероятность - придумывание контекста (когда режешь задачу на подзадачи и даёшь llm узкий сценарий, она будет реализовывать решение в контексте наиболее вероятного в выборке обучения, что может сильно не совпадать с реальностью)
Так что на бумаге звучит отлично, на практике имеет ограниченную применимость
Эмерджентность не доказана!
Пока что успехи моделирования говорят о том, что свойства систем полностью определяются свойствами ее составляющих.
Проблема только в мощности моделирующей машины. Т.е. в конечном счете в энергии.
Если нет математического доказательства, это не значит, что нет самой проблемы. Есть масса примеров от поведения молекул, до колоний насекомых.
Можно конечно упереться и сказать что мы недостаточно моделируем, но на примере простых задач - например знаменитой задачи трёх тел - можно заметить что далеко не всё мы можем смоделировать как минимум сейчас. Значит в практическом случае для нас все равно она есть.
В программах ситуация когда каждый блок в тестах ведёт себя корректно, а система в целом нет, не новость - когда речь про сложные асинхронные системы.
Есть универсальный алгоритм решения задач и проблем, любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов, когда для каждой микро задачи будет готово решение можно провести обратно - композицию.
Задачу вы откуда возьмёте? Просто тикет скините? Как вы банально узнаете что и куда добавлять? Как вы будете поддерживать консистентность разных частей системы? Как вы объясните нейронке что функция из 976 и 3469 тикета — это одно и тоже хотя называется по разному? А из 495 и 4768 — разные хотя обозваны одинаково и надо исправить?
Каким образом, работа с агентами может улучшить написание следующего кода: у нас есть аудио с речью, речь как мы знаем можно разделить на форманты F0-F5 (для примера ограничимся F5)? Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту. Вот правильный код на основе praat, который ни одна LLM не смогла написать:
Скрытый текст
def change_formants_shifts(signal, sr, formant_shifts, formants=None):
"""
Изменяет частоты формант в аудиофайле на фиксированное значение для каждой форманты.
"""
if formants:
frequencies = formants["frequencies"]
times = formants["voiced_times"]
else:
frequencies, times, _, _ = formant_frequencies(signal, sr)
# Определение функции для получения новой частоты форманты
def get_new_formant_freq(original_freq, formant_num):
if original_freq <= 0:
return original_freq
return original_freq + formant_shifts[formant_num]
# Создание нового объекта звука для изменённого звука
modified_signal = np.copy(signal)
# Итерация по каждому временно́му шагу и изменение частот формант
for t_idx, t in enumerate(times):
for i in range(5): # Форманты F1 до F5
original_freq = frequencies[i][t_idx]
if original_freq > 0: # Убедиться, что частота форманты действительна
new_freq = get_new_formant_freq(original_freq, i)
# Расчёт коэффициента ресэмплинга
resample_ratio = new_freq / original_freq
# Регулировка значений звука вокруг частоты форманты
segment_start = max(0, int(t * sr) - int(sr / 50))
segment_end = min(len(signal), int(t * sr) + int(sr / 50))
segment = signal[segment_start:segment_end]
# Ресэмплинг сегмента для изменения частоты форманты
resampled_segment = resample(segment, int(len(segment) * resample_ratio))
# Регулировка длины для соответствия оригинальному сегменту
if len(resampled_segment) > (segment_end - segment_start):
resampled_segment = resampled_segment[:segment_end - segment_start]
elif len(resampled_segment) < (segment_end - segment_start):
pad_width = (segment_end - segment_start) - len(resampled_segment)
resampled_segment = np.pad(resampled_segment, (0, pad_width), mode='constant')
# Добавление ресэмплированного сегмента к изменённым значениям
modified_signal[segment_start:segment_end] = resampled_segment
modified_signal = np.clip(modified_signal, -1, 1)
return modified_signal, srВы хоть обложитесь сотней агентов, они не сделают.
Напишут они код? Да напишут.
Будет он делать то что нужно? Нет.
Могут в этом помочь отладчики или консоль или что-то еще? Нет.
Знают ли модели о проблемах, если начать разбирать их код? Конкретно о каждой проблеме они всегда что-то напишут.
Могут ли они сразу перечислить все возможно проблемы, чтобы учесть их? Нет.
То есть на выходе вы получите выполняющийся без ошибок код, который будет делать что угодно, только не то что нужно.
Данный пример с аудио, просто один из таких примеров. В реальной работе их множество, когда мы не можете простым выполнением кода, проверить правильный результат или нет. И как уже написал, даже если ваш агент будет заранее рассуждать о возможных проблемах, задачу это не решит и вероятней всего на выходе вы получите "фарш".
Вероятно с этим смогут справиться будущие модели, которые добавят на вход и на выход аудио модальность. Так или иначе для таких конкретных моментов можно использовать подход human in a loop, то есть настроить с машиной взаимодействие так, что единственное на что она будет отвлекать внимание человека, это на обратную связь по аудио файлам. С другой стороны в некоторых случаях, вероятно уже есть модели с аудио модальностью и можно это решить сочетая несколько нейросетей вместе, что само по себе тоже задача, которую вероятно AI агент мог бы решить, если бы у него возникли бы сложности подсказки от человека помогли бы.
Замените пример proxy3d на любую другую не стандартную (не обязательно даже узкоспецилизированную) задачу и получите тот же результат. Так и будем надеятся на абстрактные будущие модели каждый раз?
Даже я, как человек никогда не занимавшийся rocket science, за свою карьеру делал достаточно задач, которые нейронки не осилят (или умножат время разработки на x2 и более) просто потому что это задачи редко встречающияся за пределами определенных отраслей и в случаях, близким к 100%, эти задачи не имеют готовых не-коммерческих решений на которых можно было бы обучить LLM.
Я понимаю, что большая часть работы программистов в конторах среднего звена - это перекладывание json'ов и круды и вот с этим LLM уже научились более-менее прилично справляться (и то за бездумные коммиты LLM кода я бы бил бы по рукам разрабу на код ревью), но есть и другие задачи.
В этих редко встречающихся задачах что, какие-то уникальные принципы программирования используются, которые в других задачах не встречались? Не думаю. А значит LLM сможет их применить в новой предметной области.
Вам уже выше пример привели, вам мало этого?
Вы меня извините, но после комментирования в десятке статей про LLM у меня начало складыватся впечатление, что люди по другую сторону баррикад уже и чтение комментариев отдают LLM.
Вообще да, мало. Одиночный пример на основе малоизвестной библиотеки, который не проверить, без промптов, без полного описания задачи совсем неубедителен. Вполне возможно, что при правильных промптах модель вполне себе сделает что нужно, к тому же с каждой версией модели новые возможности обретают. Но одни используют вполне в работе, другие - свято верят, что дальше "Hello world" модели ни на что не способны в принципе.
Hello world" модели ни на что не способны
Еще, может, "здравствуй" "мир" способны. А все ли вставят запятую?
Paart очень известная библиотека. Там же дело не в библиотеке, а к логике реализации. Такие же проблемы возникают и с базами данных. Вот простой пример, который нормально не могут осилить LLM. Нужно перенести SQL с MS SQL на Postgres, это по-моему часть кода одного из отчетов. Ниже два примера MS SQL которые нужно перенести на Postgres. В данном случае есть некоторые участки, где синтаксис будет сильно отличаться или даже может не оказаться аналога. А если еще учесть, что надо динамический запрос, то все усложняется. Вот такие реальные задачи встречаются в жизни.
В первом, LLM постоянно что-то выкидывает, что-то теряет, упускает детали.
Скрытый текст
-- Устанавливаем первый день недели понедельником
SET datestyle = ISO, DMY;
-- Курсор для создания временной таблицы со временем простоя
DO $$
DECLARE
branch_id INT;
work_place_id INT;
wevent INT;
event_time TIMESTAMP;
temp_branch_id INT;
temp_work_place_id INT;
temp_event_time TIMESTAMP;
temp_beg_time TIMESTAMP := NULL;
result_time INTERVAL := INTERVAL '0 seconds';
service_id INT;
service_group_id INT;
BEGIN
DROP TABLE IF EXISTS temp_idle_time_table;
-- Создаем временную таблицу
CREATE TEMP TABLE temp_idle_time_table (
"BRANCH_ID" INT,
"WORK_PLACE_ID" INT,
"EVENT_TIME" DATE,
"IDLE_TIME" INTERVAL
);
-- Цикл для обработки данных
FOR branch_id, work_place_id, wevent, event_time IN
SELECT
ts."BRANCH_ID",
ts."WORK_PLACE_ID",
ts."WEVENT",
ts."EVENT_TIME"
FROM "public"."WP_STATE_STAT" ts
WHERE ts."EVENT_TIME" BETWEEN '2024-09-02'::DATE AND '2024-12-02'::DATE
AND ts."BRANCH_ID" IN (1012)
AND ts."WEVENT" IN (5, 6)
ORDER BY ts."BRANCH_ID", ts."WORK_PLACE_ID", ts."EVENT_TIME", ts."WP_STATE_STAT_ID"
LOOP
-- Проверка смены группы
IF temp_event_time IS NOT NULL AND (
DATE(temp_event_time) <> DATE(event_time) OR
work_place_id <> temp_work_place_id OR
branch_id <> temp_branch_id
) THEN
INSERT INTO temp_idle_time_table ("BRANCH_ID", "WORK_PLACE_ID", "EVENT_TIME", "IDLE_TIME")
VALUES (temp_branch_id, temp_work_place_id, DATE(temp_event_time), result_time);
temp_branch_id := branch_id;
temp_work_place_id := work_place_id;
temp_event_time := event_time;
temp_beg_time := NULL;
result_time := INTERVAL '0 seconds';
END IF;
-- Обработка события WEVENT = 5 или 6
IF wevent = 5 THEN
temp_beg_time := event_time;
ELSE
IF temp_beg_time IS NOT NULL THEN
result_time := result_time + (event_time - temp_beg_time);
temp_beg_time := NULL;
END IF;
END IF;
-- Сохранение текущих данных
temp_branch_id := branch_id;
temp_work_place_id := work_place_id;
temp_event_time := event_time;
END LOOP;
-- Финальная вставка последнего блока
IF temp_event_time IS NOT NULL THEN
INSERT INTO temp_idle_time_table ("BRANCH_ID", "WORK_PLACE_ID", "EVENT_TIME", "IDLE_TIME")
VALUES (temp_branch_id, temp_work_place_id, DATE(temp_event_time), result_time);
END IF;
-- Создаем временную таблицу
DROP TABLE IF EXISTS temp_level_table;
CREATE TEMP TABLE temp_level_table AS
SELECT *
FROM public.FUNC_SRV_PARENT_LEVEL(NULL, NULL, NULL);
-- Добавляем услуги, у которых нет группы
INSERT INTO temp_level_table ("SERVICE_ID")
SELECT s."SERVICE_ID"
FROM "public"."SERVICES" s
WHERE s."BRANCH_ID" = 0
AND s."SERVICE_GROUP_ID" IS NULL;
-- Обрабатываем услуги с группами
FOR service_id, service_group_id IN
SELECT s."SERVICE_ID", s."SERVICE_GROUP_ID"
FROM "public"."SERVICES" s
WHERE s."SERVICE_GROUP_ID" IS NOT NULL
AND s."BRANCH_ID" = 0
LOOP
-- Для каждой услуги добавляем уровни вложенности
INSERT INTO temp_level_table
SELECT *
FROM public.FUNC_SRV_PARENT_LEVEL(0, service_id, service_group_id);
END LOOP;
WITH weekly_periods AS (
SELECT
TS."REG_TIME",
'№' || EXTRACT(WEEK FROM TS."REG_TIME") || ' (' ||
TO_CHAR(DATE_TRUNC('week', TS."REG_TIME") - INTERVAL '1 day', 'DD.MM.YYYY') || ' - ' ||
TO_CHAR(DATE_TRUNC('week', TS."REG_TIME") + INTERVAL '5 day', 'DD.MM.YYYY') || ')'
AS "PERIOD_WEEK"
FROM "TICKETS" AS TS
),
hourly_periods AS (
SELECT
ts."REG_TIME",
TO_CHAR(ts."REG_TIME", 'HH24:00') || ' - ' || TO_CHAR(ts."REG_TIME", 'HH24:59') AS "PERIOD_HOUR"
FROM "TICKETS" ts
)
SELECT
-- Группы отделений и отделения
brgr."BRANCHES_GROUP_NAME" AS BGROUP_NAME,
br."BRANCH_NAME" AS BRANCH_NAME,
-- Уровни вложенности услуги по группам
t."SERVICE_GROUP_NAME_LEV1",
t."SERVICE_GROUP_NAME_LEV2",
t."SERVICE_GROUP_NAME_LEV3",
t."SERVICE_GROUP_NAME_LEV4",
t."SERVICE_GROUP_NAME_LEV5",
t."SERVICE_GROUP_NAME_LEV6",
-- Услуга
sr."SERVICE_NAME" AS SERV_NAME,
-- Приоритет
pr."PRIORITY_NAME",
-- Год
EXTRACT(YEAR FROM ts."REG_TIME") AS PERIOD_YEAR,
-- Месяц (прописью)
TO_CHAR(ts."REG_TIME", 'Month') AS PERIOD_MONTH,
-- Неделя (формат: №Недели (дата первого дня недели - дата последнего дня недели))
wp_week."PERIOD_WEEK",
-- День
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY') AS PERIOD_DAY,
-- Час (часовой период)
hp."PERIOD_HOUR",
-- ФИО сотрудника
CASE
WHEN ts."WORK_USER_ID" IS NULL THEN ' '
ELSE COALESCE(wu."LAST_NAME", '') || ' ' || COALESCE(wu."FIRST_NAME", '') || ' ' || COALESCE(wu."PATRONYMIC", '')
END AS WU_NAME,
-- Рабочее место
wp."WORK_PLACE_NAME" AS WORK_PLACE_NAME,
-- Время включения/выключения рабочего места
(
SELECT TO_CHAR(wps."EVENT_TIME", 'HH24:MI')
FROM public."WP_STATE_STAT" wps
WHERE wps."BRANCH_ID" = ts."BRANCH_ID"
AND wps."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND wps."WEVENT" = 1
AND wps."EVENT_TIME" BETWEEN DATE_TRUNC('day', ts."REG_TIME") AND DATE_TRUNC('day', ts."REG_TIME") + INTERVAL '1 day'
ORDER BY wps."EVENT_TIME"
LIMIT 1
) AS switch_on,
(
SELECT TO_CHAR(wps."EVENT_TIME", 'HH24:MI')
FROM public."WP_STATE_STAT" wps
WHERE wps."BRANCH_ID" = ts."BRANCH_ID"
AND wps."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND wps."WEVENT" = 2
AND wps."EVENT_TIME" BETWEEN DATE_TRUNC('day', ts."REG_TIME") AND DATE_TRUNC('day', ts."REG_TIME") + INTERVAL '1 day'
ORDER BY wps."EVENT_TIME" DESC
LIMIT 1
) AS switch_off,
-- Всего по услуге
COUNT(*) AS RECS_COUNT,
-- Обслужено
SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS SERVICED,
-- Не обслужено
COUNT(*) - SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS NOT_SERVICED,
-- Не вызваны
SUM(CASE WHEN ts."SERVE_UP" IN (0, 5, 6) THEN 1 ELSE 0 END) AS NOT_CALLED,
-- Неявка
SUM(CASE WHEN ts."SERVE_UP" = 3 THEN 1 ELSE 0 END) AS ABSENT,
-- Отложены
SUM(CASE WHEN ts."SERVE_UP" = 4 THEN 1 ELSE 0 END) AS DELAYED,
-- Среднее время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0
THEN TO_CHAR(SUM(EXTRACT(EPOCH FROM ts."SERV_TIME" - ts."CALL_TIME")) / SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END), 'HH24:MI:SS')
ELSE ''
END AS AVG_SERVE_TIME,
-- Максимальное время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0
THEN TO_CHAR(MAX(ts."SERV_TIME" - ts."CALL_TIME"), 'HH24:MI:SS')
ELSE ''
END AS MAX_SERVE_TIME
-- Дополнительно добавить другие вычисления аналогично
FROM "TICKETS" ts
LEFT JOIN "BRANCHES" br ON br."BRANCH_ID" = ts."BRANCH_ID"
LEFT OUTER JOIN "BRANCHES_GROUPS" brgr ON brgr."BRANCHES_GROUP_ID" = br."BRANCHES_GROUP_ID"
LEFT JOIN "WORK_USERS" wu ON wu."WORK_USER_ID" = ts."WORK_USER_ID" AND wu."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "SERVICES" sr ON sr."SERVICE_ID" = ts."SERVICE_ID" AND sr."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN temp_level_table t ON t."SERVICE_ID" = ts."SERVICE_ID"
LEFT JOIN "WORK_PLACES" wp ON wp."WORK_PLACE_ID" = ts."WORK_PLACE_ID" AND wp."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "PRIORITIES" pr ON pr."PRIORITY_ID" = ts."PRIORITY_ID" AND pr."BRANCH_ID" = 0
LEFT JOIN temp_idle_time_table tmp ON tmp."BRANCH_ID" = ts."BRANCH_ID"
AND tmp."WORK_PLACE_ID" = ts."WORK_PLACE_ID"
AND tmp."EVENT_TIME" = CAST(ts."REG_TIME" AS DATE)
LEFT JOIN weekly_periods wp_week ON wp_week."REG_TIME" = ts."REG_TIME"
LEFT JOIN hourly_periods hp ON hp."REG_TIME" = ts."REG_TIME"
WHERE
ts."QMS_DELETED" = FALSE
AND ts."SERVICE_ID" > 0
AND ts."REG_TIME" BETWEEN '2024-09-02' AND DATE '2024-12-01' + INTERVAL '1 day'
AND EXTRACT(HOUR FROM ts."REG_TIME") BETWEEN 0 AND 23
AND ts."BRANCH_ID" IN (1012)
--AND ts."SOURCE_RECORD_KIND" IN (1, 2, 3, 5, 6)
AND EXISTS (
SELECT 1
FROM "WORK_USERS" u
WHERE ts."BRANCH_ID" = u."BRANCH_ID"
)
GROUP BY
brgr."BRANCHES_GROUP_NAME",
br."BRANCH_NAME", ts."BRANCH_ID",
sr."SERVICE_NAME", ts."SERVICE_ID",
t."SERVICE_GROUP_NAME_LEV1", t."SERVICE_GROUP_NAME_LEV2", t."SERVICE_GROUP_NAME_LEV3",
t."SERVICE_GROUP_NAME_LEV4", t."SERVICE_GROUP_NAME_LEV5", t."SERVICE_GROUP_NAME_LEV6",
pr."PRIORITY_NAME",
EXTRACT(YEAR FROM TS."REG_TIME"),
TO_CHAR(TS."REG_TIME", 'Month'),
wp_week."PERIOD_WEEK",
TO_CHAR(TS."REG_TIME", 'DD.MM.YYYY'),
ts."REG_TIME",
hp."PERIOD_HOUR",
ts."WORK_USER_ID", wu."LAST_NAME", wu."FIRST_NAME", wu."PATRONYMIC",
"WORK_PLACE_NAME", ts."WORK_PLACE_ID"
ORDER BY
BGROUP_NAME,
BRANCH_NAME,
"SERVICE_GROUP_NAME_LEV1", "SERVICE_GROUP_NAME_LEV2", "SERVICE_GROUP_NAME_LEV3",
"SERVICE_GROUP_NAME_LEV4", "SERVICE_GROUP_NAME_LEV5", "SERVICE_GROUP_NAME_LEV6",
SERV_NAME,
PERIOD_YEAR,
PERIOD_MONTH,
"PERIOD_WEEK",
CAST(ts."REG_TIME" AS DATE),
"PERIOD_HOUR",
ts."WORK_USER_ID", wu."LAST_NAME", wu."FIRST_NAME", wu."PATRONYMIC",
pr."PRIORITY_NAME",
WORK_PLACE_NAME;
/*Удаляем за собой временную таблицу*/
drop table temp_level_table;
drop table temp_idle_time_table;
END $$;Во втором, просто тупо допускает ошибки не понимания в чем дело. LLM использует string_agg при конвертировании, и упускает некоторые моменты особенности Postgres при работе с string_agg. Из за этого код она пишет, код при выполнении иногда выдаст ошибку, LLM пытается ее исправить, но зациклено по кругу исправляет одно и тоже, не понимая некоторых нюансов работы string_agg.
Скрытый текст
-- Устанавливаем язык вывода дат
SET datestyle = 'ISO, DMY';
WITH weekly_periods AS (
SELECT
ts."REG_TIME",
'№' || EXTRACT(WEEK FROM ts."REG_TIME") ||
' (' || TO_CHAR(ts."REG_TIME" - INTERVAL '1 day' * (EXTRACT(DOW FROM ts."REG_TIME") - 1), 'DD.MM.YYYY') ||
' - ' || TO_CHAR(ts."REG_TIME" + INTERVAL '1 day' * (7 - EXTRACT(DOW FROM ts."REG_TIME")), 'DD.MM.YYYY') || ')' AS "PERIOD_WEEK"
FROM "TICKETS" ts
),
hourly_periods AS (
SELECT
ts."REG_TIME",
TO_CHAR(ts."REG_TIME", 'HH24:00') || ' - ' || TO_CHAR(ts."REG_TIME", 'HH24:59') AS "PERIOD_HOUR"
FROM "TICKETS" ts
)
SELECT
-- Группы отделений и отделения
brgr."BRANCHES_GROUP_NAME" AS "BGROUP_NAME",
br."BRANCH_NAME" AS "BRANCH_NAME",
-- Роль
COALESCE(wp."WP_ROLE_NAME", ' ') AS "ROLE_NAME",
-- Услуга
sr."SERVICE_NAME" AS "SERV_NAME",
-- Год
EXTRACT(YEAR FROM ts."REG_TIME") AS "PERIOD_YEAR",
-- Месяц (прописью)
TO_CHAR(ts."REG_TIME", 'Month') AS "PERIOD_MONTH",
-- Неделя
wp_week."PERIOD_WEEK",
-- День
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY') AS "PERIOD_DAY",
-- Час (часовой период)
hp."PERIOD_HOUR",
-- Всего по услуге
COUNT(*) AS "RECS_COUNT",
-- Обслужено
SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS "SERVICED",
-- Не обслужено
COUNT(*) - SUM(CASE WHEN ts."SERVE_UP" = 2 THEN 1 ELSE 0 END) AS "NOT_SERVICED",
-- Среднее время обслуживания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0 THEN
TO_CHAR(AVG(ts."SERV_TIME" - ts."CALL_TIME")::interval, 'HH24:MI:SS')
ELSE '00:00:00'
END AS "AVG_SERVE_TIME",
-- Среднее время ожидания
CASE
WHEN SUM(CASE WHEN ts."SERVE_UP" = 2 AND ts."CALL_TIME" IS NOT NULL THEN 1 ELSE 0 END) > 0 THEN
TO_CHAR(AVG(ts."CALL_TIME" - ts."REG_TIME")::interval, 'HH24:MI:SS')
ELSE '00:00:00'
END AS "AVG_WAITING_TIME",
-- Ожидающие менее
SUM(CASE
WHEN ts."CALL_TIME" IS NOT NULL AND (EXTRACT(EPOCH FROM ts."CALL_TIME" - ts."REG_TIME") / 60) < 0 THEN 1 ELSE 0
END) AS "WAITING_LESS",
-- Обслуживающиеся менее
SUM(CASE
WHEN ts."CALL_TIME" IS NOT NULL AND ts."SERVE_UP" = 2 AND (EXTRACT(EPOCH FROM ts."SERV_TIME" - ts."CALL_TIME") / 60) < 0 THEN 1 ELSE 0
END) AS "SERVING_LESS"
FROM "TICKETS" ts
LEFT JOIN "BRANCHES" br ON br."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "BRANCHES_GROUPS" brgr ON brgr."BRANCHES_GROUP_ID" = br."BRANCHES_GROUP_ID"
LEFT JOIN "WP_ROLES" wp ON wp."WP_ROLE_ID" = ts."WP_ROLE_ID" AND wp."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN "SERVICES" sr ON sr."SERVICE_ID" = ts."SERVICE_ID" AND sr."BRANCH_ID" = ts."BRANCH_ID"
LEFT JOIN weekly_periods wp_week ON wp_week."REG_TIME" = ts."REG_TIME"
LEFT JOIN hourly_periods hp ON hp."REG_TIME" = ts."REG_TIME"
WHERE
ts."QMS_DELETED" = false
AND ts."SERVICE_ID" > 0
AND ts."REG_TIME" BETWEEN :PDATE_FROM AND :PDATE_TO
AND EXTRACT(HOUR FROM ts."REG_TIME") BETWEEN :HOUR_FROM AND :HOUR_TO
AND ts."BRANCH_ID" IN (14)
AND ts."SOURCE_RECORD_KIND" IN (1, 2, 3, 5, 6)
AND EXISTS (
SELECT 1
FROM "WP_ROLES" r
INNER JOIN "WP_ROLES_ITEMS" ri ON ri."BRANCH_ID" = r."BRANCH_ID" AND ri."WP_ROLE_ID" = r."WP_ROLE_ID"
WHERE ts."BRANCH_ID" = r."BRANCH_ID" AND r."IS_USED" = true AND ri."SERVICE_ID" = ts."SERVICE_ID"
)
GROUP BY
brgr."BRANCHES_GROUP_NAME",
br."BRANCH_NAME",
sr."SERVICE_NAME",
wp."WP_ROLE_NAME",
wp_week."PERIOD_WEEK",
hp."PERIOD_HOUR",
EXTRACT(YEAR FROM ts."REG_TIME"),
TO_CHAR(ts."REG_TIME", 'Month'),
TO_CHAR(ts."REG_TIME", 'DD.MM.YYYY')
ORDER BY
"BGROUP_NAME",
"BRANCH_NAME",
"ROLE_NAME",
"SERV_NAME",
"PERIOD_YEAR",
"PERIOD_MONTH",
"PERIOD_WEEK",
"PERIOD_DAY",
"PERIOD_HOUR";
Подобные вещи встречаются сплошь и рядом.
Никто не утверждает, что модели уже совершенны и с первого промпта решают задачи любой сложности. Человек тоже не решает. Я понимаю о чём вы пишете, у меня была задача очень навороченной обработки JSON и там даже примеры ей было сложно давать, упиралось в контекст, в мой в том числе, потому что задача плохо разбивалась на части и охватить её в голове всю сразу было сложно - несколько этапов преобразований, множество нюансов. Но у меня не было ожиданий, что всё будет решено и понято правильно сразу. Пробовал разные промпты, указывал ей на ошибки, уточнял задачу, не вполне верно понятую изначально. В итоге одна из моделей переосмыслила подход, упростила и выдала рабочий вариант, который, впрочем, тоже требовал доработки. Реализация нужной задачи моделью это диалог, включающий иногда и мозговой штурм, и переосмысление того, что ты хочешь получить, доуточнение задачи. Сколько примеров, когда программисты неправильно понимают задачу и делают не то. Само преобразование текст-код бывает неоднозначным из-за неоднозначностей языка.
Я не знаю какие вы промпты использовали, насколько корректно задавали описание. Попробуйте промпт вроде того, что в статье указан. Очень помогает сначала запрашивать план выполнения и только когда убедились, что задача верно понята, просить код. В принципе агентские системы уже сами себе такие планы строят, но лишним не будет. Когда контекст засорён ошибочными предположениями, результат уже хуже.
Простите, я из чистого любопытства, не обладая никаким знанием предметной области, и посредственным знанием (прикладным) Python, попытался что-то получить исходя из поставленной задачи "Мы хотим написать функцию, которая сдвинет указанную форманты на некоторую частоту".
Код совершенная чушь или как утверждает модель -- "другой подход"?
shift_formant_in_lpc
import numpy as np
def shift_formant_in_lpc(lpc_coeffs, sample_rate, formant_index, shift_hz):
"""
Сдвигает указанную форманту на заданное количество герц.
formant_index: 0 = F1, 1 = F2, и т.д.
shift_hz: на сколько сдвинуть (положительное — вверх, отрицательное — вниз)
Возвращает новые LPC-коэффициенты.
"""
# Находим корни полинома
roots = np.roots(lpc_coeffs)
# Переводим в полярные координаты (частота, magnitude)
angles = np.angle(roots)
magnitudes = np.abs(roots)
freqs = angles * sample_rate / (2 * np.pi)
# Находим пары сопряжённых корней с положительной частотой
# и сортируем по частоте, чтобы найти нужную форманту
positive_mask = freqs > 0
positive_indices = np.where(positive_mask)[0]
# Сортируем индексы по частоте
sorted_indices = positive_indices[np.argsort(freqs[positive_indices])]
# Фильтруем: оставляем только "настоящие" форманты (90-5000 Hz)
formant_indices = []
for idx in sorted_indices:
f = freqs[idx]
bw = -np.log(magnitudes[idx]) * sample_rate / np.pi
if 90 < f < 5000 and bw < 500:
formant_indices.append(idx)
# Проверяем, есть ли нужная форманта
if formant_index >= len(formant_indices):
# Форманта не найдена — возвращаем без изменений
return lpc_coeffs
# Индекс корня, который будем сдвигать
root_idx = formant_indices[formant_index]
# Текущая частота и новая частота
old_freq = freqs[root_idx]
new_freq = old_freq + shift_hz
# Ограничиваем разумным диапазоном
new_freq = np.clip(new_freq, 90, sample_rate / 2 - 100)
# Новый угол
new_angle = new_freq * 2 * np.pi / sample_rate
# Модифицируем корень (сохраняем magnitude, меняем угол)
roots[root_idx] = magnitudes[root_idx] * np.exp(1j * new_angle)
# Находим и модифицируем сопряжённый корень
# (он имеет ту же magnitude и противоположный угол)
conjugate_idx = np.where(
(np.abs(magnitudes - magnitudes[root_idx]) < 1e-10) &
(np.abs(angles + angles[root_idx]) < 1e-10)
)[0]
if len(conjugate_idx) > 0:
roots[conjugate_idx[0]] = magnitudes[root_idx] * np.exp(-1j * new_angle)
# Пересчитываем коэффициенты из корней
new_coeffs = np.real(np.poly(roots))
# Нормализуем (первый коэффициент должен быть 1)
new_coeffs = new_coeffs / new_coeffs[0]
return new_coeffs
def shift_formant_all_frames(lpc_coeffs_all, sample_rate, formant_index, shift_hz):
"""
Применяет сдвиг форманты ко всем фреймам.
"""
new_lpc = np.zeros_like(lpc_coeffs_all)
for i, lpc in enumerate(lpc_coeffs_all):
new_lpc[i] = shift_formant_in_lpc(lpc, sample_rate, formant_index, shift_hz)
return new_lpc
# Использование
audio, sr = load_audio("input.wav")
frames, hop = split_into_frames(audio, sr)
lpc_coeffs, gains = analyze_frames(frames, lpc_order=16)
# Сдвигаем F2 на +200 Hz
new_lpc_coeffs = shift_formant_all_frames(lpc_coeffs, sr, formant_index=1, shift_hz=200)
# Проверяем, что форманты изменились
old_formants, _ = extract_formants_from_frames(lpc_coeffs, sr)
new_formants, _ = extract_formants_from_frames(new_lpc_coeffs, sr)
print(f"F2 до: {np.nanmean(old_formants[:, 1]):.0f} Hz")
print(f"F2 после: {np.nanmean(new_formants[:, 1]):.0f} Hz")объяснение моделью разницы между сгенерированным кодом и вашей функцией
уже достаточно поздно, поэтому я просто отложил в сторону этап глубокого изучения предметки, чтобы что-то понимать, это буквально один проход за сеанс. Но если бы передо мной стояла такая задача, то я решал бы ее как раз через создание базы решения, в том числе грумил бы вопрос относительно валидации результатов, вроде создания синтетических тестов.
Отдельно хочу указать, что я не ставил себе задачу опровержения вашего комментария, просто любопытно, где же все таки границы решения задач: в подготовке самой модели или в наших собственных руках.
-- модель opus 4.5.
Давайте так, если вы предлагаете решение, то не нужно просто брать и генерировать его и просить модель объяснить это решение. Стоит сначала взять и проверить его и затем уже предлагать. Если кратко то нет, в вашем случае на выходе вы услышите на фоне звука так же потрескивание или наоборот звуки скрежета.
В предложенном коде все кишит проблемами.
1) форманты содержат ширину, и ее надо учитывать. В коде выше, она считается примитивным образом как bw = -np.log(magnitudes[idx]) * sample_rate / np.pi и дальше просто идет проверка.
2) LPC очень плохо справляет на самом деле с голосом.
3) resample в описанном мной примере делается как компромисс, чтобы не потерять сильно в качестве звука. Это важное отличие, которое агенты просто не могут сделать. Нет такого понятие как компромисс, не могут они это оценить.
4) там еще не мало других проблем, вроде if 90 < f < 5000 and bw < 500 и множества других.
Синтетические тесты тут ни как не помогут. Что вы хотите в них анализировать? Как выстроите их, по какому критерию? Просто частоты сдвинулись или нет? В голосе форманты имеют обертоны, и если вы просто сдвинули какую то частоту то это не будет согласовываться например с ними.
Отлично, спасибо. Признаю, что некорректно такое кидать без проверки, но это далеко за пределами скоупа моей текущей работы. Приношу извинения.
Однако, сохраню как полезный кейс: будет время, попробую проверить, насколько модель может сократить вход в другую прикладную область с полноценной отдачей. Вы абсолютно правы, что llm не решает вашего кейса, и, возможно, долго не решит. Но 80% задач бизнеса никто не отменял -- на мой взгляд хорошая модель типа опуса может саппортить их. Да, собственно, я так и делаю сейчас.
А вы уверены, что код верный, а то три нейросети (Claude Opus 4.5 thinking, Google Gemini 3 Pro, ChatGPT 5.2 Thinking) дружно его критикуют? Они могут ошибаться, но как правило всё-таки находят узкие места. Я не разбираюсь ни в этой библиотеке, ни в Python и не хочу быть испорченным телефоном, но всё же рекомендовал бы спросить что они думают о коде и почитать, вполне возможно что выявятся скрытые проблемы. Например, они утверждают, что это некорректный сдвиг, что будут артефакты, что есть неэффективность по производительности. Когда разные модели солидарны, это как правило признак какой-то проблемы.
Praat это самая популярная и эффективная библиотека при работе с голосом. Все LLM ее знают и все равно галлюцинируют на ней часто обращаясь к тому чего нет. Как уже было сказано выше, да она правильная, так как использовал ее при изменении голоса.
Ниже пример, где также используется эта функция. Я прекрасно знаю что на все это пишут LLM, проблема в том, что они не могут не писать, даже там где имеют проблемные места.
Я использую LLM, просто у них есть границы применимости.
Ну, я вот слышу металлизированный робоголос, о котором одна из моделей и писала, как о следствии именно такого, не вполне корректного преобразования и предлагала другое. Звук явно не очень естественный. Но, ещё раз, мне сложно оценивать, я в теме не разбираюсь. Вполне возможно галлюцинации сразу трёх моделей.
Вот еще Grok 4.1 Thinking подключил. Нет, что-то там определённо не то, раз им всем не нравится:
Минусы и потенциальные ошибки
Концептуальная проблема с ресэмплингом:
Ресэмплинг всего сегмента сдвигает весь спектр (все частоты), а не только одну формант. Если ты хочешь сдвинуть только F1 (например, с 500 Гц на 600 Гц), но оставишь F2-F5 на месте, этот метод сломает гармонику. В итоге звук может стать "металлическим" или неестественным.
Лучше использовать методы вроде LPC (Linear Predictive Coding) или фазового вокодера для избирательного сдвига формант. В библиотеках типа Librosa или PyDub это реализовано лучше.
Он написал чушь.
1) я написал что это компромиссное решение, которое по качеству лучшее. Ого как раз захватывает гармоники через ширину, в то время как в сетки в коде даже этого не делают.
2) LPC делает гораздо, гораздо хуже. Он не приспособлен идеально к речи. Естественно у меня есть код этого через librosa, но там звучание гораздо хуже. Так как librosa больше подходит для неречевых звуков. Что касается pydub, то и с ним у меня была реализация и там тоже что-то было не так. Из всех вариантов, был выбран наиболее лучший по качеству с учётом компромиссов. Остальные давали результат гораздо хуже или ломали что-то ещё.
Вместо того чтобы полагаться на сетки надо проверять, а уже затем утверждать. В этом и заключается проблема, если полагаться на то что утверждает сетка. Я прекрасно знаю, что они отвечают, так как использую их и они в этих моментах очень сильно тупят. И я молчу уже о том, что решая проблему они могут выкинуть что то уже рабочее в коде, какую то деталь, упростить расчет и так далее.
Что вам не нужно: имена переменных, форматирование, комментарии для людей или паттерны, придуманные только для того, чтобы пощадить ваш мозг.
Ну-ну. То есть, вы утверждаете, что ИИ не нужен читабельный код? Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией main и переменными с именами a,b,c, без строгой типизации и с размазанной по всех кодовой базе логикой, то нейронка сможет так же легко читать и поддерживать этот код? Sweet summer child...
А ещё я бы не разделял код на "оптимизированный для LLM" и "оптимизированный для человека". LLM обучили работать с кодом так же, как это делает человек. Они так же юзают grep для навигации по кодовой базе, запускают тесты, линтер, читают логи, анализируют коды ошибок. Если кодовая база написана хорошо, есть тесты, правильное разбиение на модули, логирование, правильная обработка ошибок - то поддерживать это будет легко как человеку, так и нейронке. Если код изначально написан плохо - то плохо будет для обоих. Но только опытный разработчик может решить, что пора всё отрефакторить, переписать. Выкинуть старую архитектуру на определённом этапе и сделать хорошо. А нейронка будет вставлять костыли, фиксить одно, и в то же время ломая другое.
Для ИИ нужен так же как и для людей хороший CI/CD который гарантирует что код читается и нужного качества. И самое критичное скажем для Claude Code CLI агента, это то, что если CI/CD требует чтобы каждый файл с кодом или документацией будет меньше 1500 строк, то у Claude Code CLI будет намного больше шансов прочитать его целиком, а следовательно полностью осознанно сделать правки. Плюс такое ограничение вынуждает агента разделять код на файлы. В общем все те лучшие практики программирования которые накапливали люди за это время на текущий момент применимы так же, и иногда даже критичнее для AI чем для людей.
Качество кода - это несколько более широкое понятие, чем просто разбить код на небольшие читаемые куски. Это какая же CI/CD система способна например определить, что код нарушает принцип open/close, или что там захардкожено что-то что захардкожено быть не должно, или что библиотека даёт вызывающему возможность парой вызовов апи привести данные в неконсистентное состояние? Пусть этот код даже разбит на вылизанные куски и снабжён мильоном .md документов?
То есть, вы утверждаете, что ИИ не нужен читабельный код?
Да , так и есть.
Мне Claude легко и влет парсит и правит любые XML, JSON файлы (ну те что мне попадались), идеально разбирается в их структуре. Не требуя никаких подсказок.
Но да, иногда делает осечки.
Но это такая милая мелочь и одновременно спасительная.
Потому что не делай он их, нам бы всем уже пришел конец.
Ну, если вы работаете джейсоноукладчиком – тогда AI вполне может справиться со всеми вашими задачами.
Claude легко и влет парсит и правит любые XML, JSON файлы (ну те что мне попадались)
У вас сравнение сломанное. XML\JSON декларируют только структуру, но не логику. А анализ исполняемого кода это не только парсинг синтаксического дерева.
Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией main и переменными с именами a,b,c, без строгой типизации и с размазанной по всех кодовой базе логикой, то нейронка сможет так же легко читать и поддерживать этот код?
На самом деле - читать вполне сможет, правда. Ради интереса скармливал исходники Java игр и приложений, восстановленные из class-файлов. То есть это как раз огромные функции, с кучей переменных aa, bb, cc, с проблемами типизации (в Java int a и double a - разные переменные и в выводе такого - дофига). Сходу человеком это не читается вообще никак.
И съев эту мешанину она радостно говорит - вот, функция aB() это обработка выстрела, а переменная bC хранит здоровье, а вот в c и d - хранятся координаты блоков уровня.
Можно даже в бесплатном DeepSeek попробовать, реально работает.
Ну-ну. То есть, вы утверждаете, что ИИ не нужен читабельный код?
LLM очень здорово анализирует результаты декомпилятора и помогает реверс-инжинирить всякую бинарщину. Т.е. тот код, где переменные априори без имён, где нет комментариев и зачастую вообще никаких человекопонятных названий чего-либо.
А я благодаря Claude Opus и Claude Sonnet больше не пишу код руками, не требуется его теперь и читать тоже, так как всегда можно задавать вопросы AI агенту. Уже более 6 месяцев я разрабатываю своего бота программиста используя Claude модели, и всё это время все свои 500+ репозиториев в open-source и в общественном достоянии поддерживаю используя этого самого бота-программиста, который мне Claude и помог написать. По сути для меня это означает первый реальный шаг к автоматизации автоматизации. Ну и конечно сам бот-программист тоже с открытым кодом и в общественном достоянии. Для меня это первое ПО, которое способно писать себя самостоятельно. Так что я очень доволен что появился ИИ и из программиста я больше трансформировался в тех-лида, который теперь принимает Pull Requests от ИИ и людей. А моя разработка фактически в одиночку помогла мне догнать и обогнать продукты крупных корпораций.
Если раньше я нанимал программистов, чтобы они помогали мне разрабатывать опенсорс проекты, то теперь такой мысли вообще не возникает. AI-агент, который интегрирован с GitHub фактически заменяет человека программиста в привычном мне flow - создать issue - сделать ревью Pull Request и смержить. Теперь я могу больше сфокусироваться на планировании и архитектуре, и поддерживать куда больше опенсорсных проектов фактически в одиночку. Поэтому с приходом ИИ ощущается что за $200 подписки Claude MAX я нанял себе целую команду разработки, которая готова работать по запросу 24/7. И разрабатывает код в десятки раз быстрее чем многие junior и middle программисты. Я может быть плохой senior программист, но за 25 лет программирования я не научился писать код вручную быстрее и точнее чем это делают AI агенты. Зато если их тех-лидить получается эффективнее на порядки.
Господи, избавь нас от лукавого!
больше не пишу код руками, не требуется его теперь и читать тоже
Но, думаю, Вы знаете язык программирования, на котором Claude пишет код, на довольно хорошем уровне, поэтому у Вас есть возможность ставить задачи максимально понятным языком и со всеми подробностями, необходимыми для решения задачи. Значит ли это, что программисты пока могут спать спокойно или в будущем всё-таки знание языка будет не нужно?
Результат определяет не знание языка программирование, а упорство и труд. То есть если хватит терпения давать подробную обратную связь AI агенту, то может получиться, что совсем не обязательно читать код который он пишет. Ведь по началу будет большее значение иметь работает ли ПО как ожидается или нет.
Ну и задавая вопросы агенту про код можно фактически начать изучать программирование и при желании изучить его полностью. То есть это может снижать порог входа в программировании.
Однако моя изначальная цель - автоматизация автоматизации - то есть возможность программировать на любом языке, в том числе человеческом. И я считаю последние 6 месяцев я программирую только используя английский язык, ну просто потому, что сейчас мне нравится изучать этот язык. ИИ конечно понимает и русский тоже.
все свои 500+ репозиториев в open-source
Даже страшно представить что там.
Зачем представлять, если можно посмотреть, а потом написать действительно полезный комментарий?
Так ссылку на эти 500+ репозиториев ни в комментарии, ни в профиле автора нет. Покажет - почитаем)
В профиле есть, в разделе "Контактная информация".
P.S. Ниже даже кто-то пишет, что не смог найти ссылку на оригинал статьи, это печально.
Оффтоп, но вот в упор не вижу такого раздела, не подскажете, где искать? Даже поиском не отыскал.
Скрытый текст
Что же до не "находят ссылку на оригинал" - это печально, согласен, но дело то не в пользователях, а интерфейсе! Годами твердят хабру: ну контринтуитивно это, что
1) клик на имя автора оригинала переносит на пост на языке оригинала
2) не выглядит этот серый не подчёркнутый блок с именем автора оригинала как кликабельный элемент
Но воз и ныне там)
Показываю:
Картинка похожа на beam search
Картинка похожа на x в степени N, где x == 2 только в лучшем случае. Типичный комбинаторный взрыв.
Как и ожидалось - какая-то непонятная никому не нужная хрень. Зачем на такое спускать дохулиард токенов - уму не постижиму, такую дичь можно генератором случайных чисел нагенерировать.
ну вот у меня тогда более понятная (и нужная мне) хрень — парольный менеджер, ибо меня не устраивал bitwarden и его экосистема + хотелось аналог hashiecorp vault, но для "маленьких". Сейчас активно всё причёсываю, думал потом может более статью написать, не про очередной "смотрите как LLM умеет", а про сам пет проджект, может кому-то тоже пригодится.
● podman-zann.service
Loaded: loaded (/etc/systemd/system/podman-zann.service; enabled; preset: ignored)
Active: active (running) since Tue 2025-12-30 13:06:39 +04; 1 week 5 days ago
Invocation: 5f9c57b203a8480382f0a639cb9808ea
Main PID: 1722521 (conmon)
IP: 10.1K in, 5.9K out
IO: 0B read, 180K written
Tasks: 1 (limit: 18808)
Memory: 608K (peak: 11.6M)
CPU: 326ms
CGroup: /system.slice/podman-zann.service
Я прям читал и плакал. Реальность несколько более прозаична: тривиальные изменения с 5 попытки, а сложные - проще самому сделать, чем объяснить ему, что не так.
Смотря у кого :)
Пока что я вижу что более 80% pull requests завершаются мержем, а не закрытием :) Как получилось, что для тебя наш бот-программист не сработал для меня пока загадка.
Сомнительный повод для гордости. Вы же понимаете что стандарты качества у набора рандомных репо на гитхабе заметно ниже, чем в любой адекватной компании?
С вероятностью, приближающейся к 100%, почти все репозитории куда приняли эти PR сделаны в стиле "фигак-фигак и в продакшен" людьми, прямо скажем, не очень высокой квалификации. Гордиться что у вас люди непонятной квалификации принимают любой PR пока он вроде бы что-то делает и вроде бы даже правильно - ну такое себе.
Взял первый попавшийся смерженный не совсем нетривиальный реквест: https://github.com/konard/telegram-bot/pull/8
Там два изменения: одно по теме задачи, а второе, внезапно, - какие-то адовые костыли с подавлением варнинга, вместо того, чтобы закинуть пр с фиксом в gramJS, который эти варнинги и вызывает.
У меня голова заболела от одной попытки прочесть diff. И на это люди променяли право первородства...
интересно, что автор продолжает отвечать в соседних ветках, ссылаясь на свой коммент, а вот на подобные комментарии он отвечать нужным не считает
вместо того, чтобы закинуть пр с фиксом в gramJS, который эти варнинги и вызывает.
Может не у всех есть время фиксить чужие библиотеки? Может не все авторы быстро принимают ПР?
Зато у всех есть время лепить костыли, которые глушат ошибки. А форки на гитхабе вообще запрещены.
Вы можете поступать как Вам угодно. Но я лично думаю, что если бы я всегда фиксил чижие баги, потом дожидался пока примут ПР, я бы свою работу никогда не закончил. Уж лучше костыли (на время).
С таким подходом вы бы у меня так и не дождались принятия пр.
Можете покритиковать этот ПР:
https://github.com/tariqbuilds/linux-dash/pull/523
Вы готовы оплатить мои токены?
Сорян что влезаю, но вы когда PR создаёте, просто поставьте себя на место мейнтейнера.
Вы делаете PR в заброшенный проект который 6 лет не обновлялся, пытаетесь поменять кучу всего за раз с описанием в 3 строчки на 6737 строк изменений в 79 коммитах, часть которых называется upd/update*.
Просто представьте сколько времени понадобится автору на ревью?
Почему я должен думать об авторе, но не думать о себе? Если автору нужно, пусть разбирается, если не нужно, буду использовать форк. Там действительно очень много изменений, но обновлено также readme, где есть информация. По-моему разобраться не сложно.
10 коммитов "Initial commit with task details" и 10 коммитов "Revert "Initial commit with task details"" особо доставляют.
Он историю коммитов перед созданием пулл-реквеста хоть причесал бы.
Если бы это был баг. Это просто warning. Вставлять костыль чтоб зафиксить warning - это бред.
И я бы согласился если бы там был паралельный PR в gramJS, и TODO: вроде "удалить после корректного фикса" со ссылкой на него.
Там ещё и тест, который не импортирует проверяемую функцию из кода, а копипастит. Если кто-то поменяет или сломает фикс в коде - тест не упадёт.
Просто владельцы репозиториев принимают твой нейрослоп не глядя.
В моём крохотном репозитории тривиальная задача собрать CUDA приложение под линукс превратилась в чудовищный PR со 102 сообщениями, 41 коммитами и 1229 добавленными строками кода, которые делают вид, что работают и генерируют бинарники длиной 0 байт.
Самые лучшие в мире бинарники
Каждый раз ты довольный приходил "1dNDN, проверяй!". А в PR килотонна нового кода с отрицательной ценностью и бинарники, которые делают вид что существуют. Сам же ты не можешь скачать артефакт и увидеть пустоту в нём - ты же благородный рыцарь, целую Нейросеть на репозиторий напустил, зачем тебе ещё что-то делать.
К счастью, я не потратил ещё больше времени на ревью только благодаря тому, что тебе совершенно случайно удалось запустить Github Actions, поэтому мне достаточно было каждый раз тебе показывать на пустой архив с артефактами, а не разглядывать внимательно всю эту килотонну кода.
А потом ты не смог повторить свой же успех, потребовав мержить непонятно что в мастер для запуска Actions в рамках второго Issue.
Самые лучшие в мире пайплайны
В итоге ты мне заявил, цитирую "Ты придумал конечно одну из сложнейших задач с которой я сталкивался.", потребовал сменить ТЗ на более простое (а куда ещё проще-то?) и попросил денег (ааааааа, меня попросили смотреть что за херню я присылаю, 2500 рублей в час!!!). А мне оказалось намного проще самому решить проблему за час, чем добиться от тебя чего-то хоть отдалённо адекватного.
Оказывается, если задача чуть сложнее hello world и владелец репозитория смотрит, что ему присылают, то сразу карета превращается в тыкву. А проверка твоего нейрослопа занимает кратно больше времени и сил, чем написание кода самому. Особенно из-за того, что ты даже не смотришь, что присылаешь и, по сути, предлагаешь владельцу репозитория пообщаться с нейросетью через твоего бота.
Шутка на тему
Сижу я как-то на гитхабе. И тут вижу, бедному опенсорсеру открывают один пулл-реквест навайкоженный. Я стою и думаю: да что же за индустрия у нас такая. почему человеку так тяжело приходится? Ну и я ему и навабайкодил еще несколько тысяч PRов, мне не жалко. Он там в процессе что-то пытался мне писать вроде "не надо", "хватит", "я тебя сейчас забаню". Но тут понятно: гордый, старой закалки.
Стоял потом на улице, курил, много думал. А опенсорсер тот все-таки на ритрит уехал, сил набраться. Ну ничего, у меня еще токенов много - приедет, еще накину. Мне не жалко хорошему человеку помочь.
del
все свои 500+ репозиториев в open‑source
«У нас есть такие приборы!..
Но мы вам про них не расскажем их не покажем.»
Показывал в комментарии выше https://habr.com/ru/articles/984026/comments/#comment_29367614. Рассказать могу - могу ответить на вопросы.
А вообще бот-программист, которого я делаю с его же собственной помощью вот тут: https://github.com/link-assistant/hive-mind
Похоже, мы работаем в одном направлении, но с абсолютно разными принципами
На мой взгляд ваша архитектура отражающая принцип, который я называю "перпетуум мобиле" имеет существенную уязвимость для промышленного решения
здесь
Скорее даже ваша архитектура противоречит вашему же манифесту в bio:
Формулировка проблемы. Этот шаг предполагает полное понимание и определение проблемы, которую необходимо решить
Issue не является "формулировкой". У вас полностью пропущен этап анализа. Либо задачи не энтерпрайз уровня, либо вы его создаете в каком-то другом флоу и формируете как issue. Мы приходим в PR непонятно с чем. С подброшенной монеткой, а не с "полным пониманием проблемы, которую необходимо решить". Может, закрыли баг с кнопкой, а может, десяток других, которые на тестах не видны, создали. Я как инженер зачем такой PR смотреть буду? Чтобы помянуть незлым тихим словом постановщика задачи?
Анализ нужен не всегда, и анализ может быть отдельной задачей и даже частью её как один из шагов. В целом на картинке анализ есть, и без анализа AI агент не может даже приступить к задаче, ведь ему нужно оглядеться, посмотреть что происходит и понять что ему делать, составить свой план и т.п.
Я также могу просто попросить провести анализ в issue, и как только он проведён в этом или отдельном Pull Request я могу попросить комментарием реализовать один из вариантов решений и т.п.
На текущий момент конечно же это Proof of Concept, и цель прежде всего дать возможность встроить похожую на программиста сущность в процесс разработки. Но универсальный алгоритм решения задач и проблем реализован на текущий момент не полностью. Если интересно можете посмотреть открытые issues (там можно обнаружить примерный roadmap разработки) или если хотите испытать эту систему в действии можете написать мне в личку.
Если говорить о том как я работаю то обычно это выглядит так: я ставлю задачу, и если считаю что она требует глубокого анализа то изначально задача ставится буквально так - провести анализ, а как только анализ проведён я могу либо в этом же Pull Request, либо уже в отдельном сделать само решение. Иногда бывает я ставлю задачу составить план реализации и по этому плану ставлю задачу создать все задачи с учётом зависимостей, чтобы у меня был полный план разработки с максимальным параллелизмом между задачами. Ведь одно из удобств системы в том, что можно запускать множество задач для решения одновременно.
То есть я ставлю задачи, если Pull Request нужно доработать я даю комментарии и отправляю агента дорабатывать. Для меня основное преимущество в том, что пока агент работает самостоятельно, а это обычно 15-35 минут рабочая сессия, он никак не отвлекает на себя моё внимание и я могу заниматься чем-то ещё. То есть у него достаточно времени чтобы провести свой анализ ситуации, провести эксперименты, и набросать черновик решения, иногда бывает что он справляется задачей с первого раза, иногда с 4-5 итераций обратной связи, в среднем за 2-3.
То есть я как инженер прихожу в Pull Request чтобы проверить а соответствуют ли предложенные правки требованиям заданным в задаче, соответствует ли код нужному мне уровню качества и т.п. Да, бывает я совершаю ошибки в постановке задачи, за это действительно приходится платить дополнительными комментариями к Pull Request, но так или иначе этот флоу позволяет завершить задачу до конца.
И как я уже говорил, это намного быстрее чем если ждать результата от программиста - часами или днями или что хуже студент может быть настолько занят учёбой что сделает задачу через несколько месяцев. А его ещё и обучать нужно было и даже мотивировать деньгами.
В целом я предпочитаю не оценивать, поэтому словами я обычно не поминаю. Меня интересуют только факты, и результат, и способы его достижения.
Так или иначе конечно чем меньше задача - тем больше шансов что с ней AI агент справится. Но сам анализ в моём понимании это тоже задача, планирование задач это тоже задача и т.п.
И лично я субъективно не вижу уязвимостей для промышленного решения, так как именно с промышленной разработкой Claude Code CLI + Claude Opus 4.5 на моём опыте и под моим управлением справлялся. А сам Hive Mind, буквально интегрируется с GitHub таким образом, чтобы в промышленный процесс разработки ПО встраиваться. И в сочетании с CI/CD настроенной для поддержки команды разработки из ИИ и людей - это работает буквально как часы или хорошо выстроенный промышленный процесс.
Ну хорошо, возьмём для примера https://github.com/konard/anime-avatar, которая "A configurable 3D anime girl avatar". Отлично, как мне получить мою кошкодевочку?
А $2000 в месяц готовы за это отдавать? Когда владельцы Claude захотят выйти на окупаемость и поднимут цену на услуги
Как нам можно про тестировать этого самого AI Агента? И будет ли снята подробная видео инструкция применения данного решения? Интересно кстати на сколько будет проще в AI-Агенте и удобнее создать свою игровое вселенную в удобном для себя как мобильном приложении, так и деск-топ в том числе. Ведь по сути дела если смотреть со стороны это создание своего цифрового джина который при достаточном вменяемом объяснении создает нам любой необходимый софт без всяких посредников, они попросту по итогу остаются за бортом и это меня лично очень радует данное освобождение всех этих людей.
Да кстати если это Smart ПО сможет ещё и без инета работать в офлайн режиме нам софт собирать да делать по нашим желаниям в удобной для нас строковой форме типичного текста простого пользователя по ZeroCode стилистике. То тогда уже будет весьма не дурно + правки и корректировки вносить можно будет в основной шаблон проекта самой заготовки. Да и в целом на будущее на клепать все необходимые шаблоны заготовок проектов с базовым функционалом, так чтобы можно было с легкостью его развивать под себя как угодно через дублирование основного макета.
Ну а так вообще это очень сверх круто. Когда само ПО настолько совершенное что может по заданным простым параметрам и атрибутам от обычного человека, оно генерирует и создаёт себе подобное ПО и даже фактический любые игровые приложения под все платформы может создать лишь бы были указаны необходимые ресурсы контента и заданы вменяемые скрипты объяснений для самого Умного ПО нашего времени.
Пока что можно ставить в докере локально или у себя на сервере и использовать свою подписку на Claude MAX $200. Так как проект в общественном достоянии и полностью с открытым исходным кодом.
Инструкция по установке доступна тут: https://github.com/link-assistant/hive-mind
Либо можно прислать ссылку на issue на GitHub мне в личку тут или в Telegram (указано в профиле), в таком случае если issue мне понравится я запущу выполнение в моей поднятой инфраструктуре. Также можно пройти отбор и попасть в наш чат, где вы сможете запускать свои задачи самостоятельно через нашего Telegram бота.
На текущий момент проект в состоянии закрытого тестирования, поэтому пока как есть. Если я вдруг запишу видео, я об этом сообщу.
Я надеюсь с вашей помощью в тестировании мы сможем и локальные модели поддержать на том же уровне, что и Claude в ближайшем будущем, но пока Claude Opus + Sonnet это лучшее предложение по соотношению цена/качество.
запускать свои задачи самостоятельно через нашего Telegram бота
Кстати, крайне не удобный способ запуска. Почему бы не попросить этого агента сделать удобный интерфейс? Или даже лучше сервис мониторинга задач на гитхабе? Приключение же на 5 минут.
Удобный интерфейс, это в виде бота на GitHub? С запуском через упоминание/assign/прикрпление тэга к задаче?
Помимо /solve команды у нас есть /hive команда в ней частично реализованы функции мониторинга, но мне пока не нравится эффективность такого подхода. Пока что на этапе тестирования текущего варианта, я считаю, достаточно, а дальше посмотрим как пойдёт. Для начала мне бы понять что для реальных пользователей является наиболее удобным форматом взаимодействия. Плюс есть ещё над чем работать чтобы улучшать стабильность и качество текущего решения.
все свои 500+ репозиториев в open-source и в общественном достоянии
У меня только один вопрос, зачем? Я понимаю если вы решаете своим проектом какую-то проблему. Реальную, а не выдуманную. Или же пишете для самообучения (как это делаю я - на работе задачи другого плана). Но выкладывать откровенный булщит непонятно зачем, тем более когда большая часть репозиториев это форки, зачем, мистер Андерсон?
25 лет программирования? Вы в 10 лет начали программировать?
Вы не поверите, действительно с 10 лет считает.
Пост вроде должен был быть про Claude Opus 4.5 а в итоге "как я сгенерировал несколько простых приложений" - вау - вроде это можно было делать и раньше с помощью no-code платформ или для продвинутых взять из ГХ
Если это перевод, а это перевод, то почему нет ссылки на оригинал?
Почему-то все преимущества AI оказываются "я с 0 сгенерил апп", а под этот шумок предполагается что он он также хорошо работает с многолетней кодовой базой, где куча зависимостей, ничего не случайно и ничего просто так не поменять.
Я уже много раз сталкивался с тем, что ИИ просто чуть переписывает функции
Чес говоря, только с такими кодовым базами и работаю. Которым по 10-15 лет и больше.
Claude нормально с ними справляется.
Да, он получив 3000 файлов , отказывается прямо все просматривать. Но по частям за полчасика , вычищает любые конюшни. С одной среды разработки в другую переводит. Убирает старую систему логов и меняет на новую. Вычищает весь мертвый код. Пишет полную доку по архитектуре и т.д. и т.п.
Пример бы
Вероятно, у вас нет кода "так исторически сложилось, никто не знает почему именно так", где эксперты ушли и ответить не смогут, а легаси код всё же работает и вы не сможете доказать что ничего не сломается при переделке
Убирает старую систему логов и меняет на новую. Вычищает весь мертвый код. Пишет полную доку по архитектуре и т.д.
Сложность ниже среднего
На работе нужно было сделать специфичный конвертор файлов. Гемини мне сделал скрипт, но GUI не смог сделать. OPUS сделал с первой попытки, 1600 строк кода. В программировании я понимаю только как установить Python и всякие библиотеки.
А я вот сегодня долго мучал и встроенного гитхабовского агента в vscode, и cursor. Нужно было сделать простой тест "с подковырочкой". Скачать тестовый файл через socks5 прокси со "спуфленным" SNI/Host хидером. (оп-па, задачка простая, но не самая типовая). Задолбался, и сделал ручками.
Вот так и будет с любым ИИ проектом. Он будет блестеть и сверкать пока он простой, но как только возникает первая запердыка в нем - проще все с нуля переписать.
Я не делал специальных тестов, но, есть ощущение, что гитхабовские модели квантитизованные. Гитхабовский sonnet "плавает" на проверке обычного симлинка (не смотрит оттуда документацию), в то время как его "оригинальный" собрат логично продолжает просмотр симлинка как директории после определения в 10 из 10 случаев.
Но как без знания программирования прочесть сгенерированный код? Или запускаете так? Ведь ни один набор тестов не гарантирует корректность.
Если мы переживаем о безопасности - можно запустить в виртуальной машине. И проверять конечно же запуском, а как иначе проверять? :) И если ручной тест показывает что юнит тесты проверяют не то - значит нужно юнит тесты поправить и со всем этим Opus справляется, ему нужно только дать эту самую обратную связь о требованиях - как должно быть и как быть не должно. Тоже самое как с обычным программированием - написал код-черновик-гипотезу - запустил - проверил - понял что не то, понял почему и как не то - исправил - перезапустил.
Конечно же мы не переживаем о безопасности. Чего о ней переживать то? Мы же просто перекладываем JSON-ы из одной базы в другую... А если/когда налоговая выкатит требование уплатить недоимку по НДС и штраф, мы скажем - Это не мы! Это вражеский ИИ все наколдобил!
Используйте тогда отечественный искусственный интеллект. НейроМакс лучшая нейросеть?
Считаете что безопасность в данном случае - это эксклюзивно лишь тема местонахождения ИИ?
Нет, не считаю. Безопасность можно и нужно тестировать. Это видимо была неудачная штука на тему "вражеского" ИИ.
Из того что ИИ пишет код, а не человек априори не следуют проблемы с безопасностью. Если стоит задача обеспечить безопасность, всегда можно сделать тестовый стенд, песочницу, где сам же ИИ направить на то, чтобы провести целый ряд атак против безопасности. Есть так же много статический чекеров на типичные уязвимости. Всегда есть способы обеспечить безопасность, если именно в этом потребность или требование. Методы мало чем будут отличаться с ИИ или без. Методики все те же самые, и исполнителем может быть не только человек, но конечно человек желателен для гарантии безопасности в критических решениях.
Никто не отменяет награды за найденные уязвимости, сертификацию и т.п., чтобы делать финальные гарантии по безопасности.
Если же речь о сохранности данных, то никогда не нужно отправлять ИИ править БД на проде, без строгого контроля, так как ИИ может не чувствовать ответственности. При этом если речь о сохранности локальных данных или системы - то желательно использовать локальную или удалённую виртуальную машину (песочницу) без доступа к интернету. А если есть доступ к интернету начинать тестировать с тестовых стендов, а не с боевого API.
Я не о безопасности, а о сопровождении. Вроде бы до недавнего времени все соглашались, что строить проекты при помощи нечеловеческих агентов нормально, если всегда проводить человеческий контроль каждой строки сгенерированного кода. Сейчас намечается тенденция вообще не читать сгенерированное. Может быть, я не успеваю за прогрессом, но это кажется... страшно?
Это называется вайб-кодинг или AI driven development. Можно не читать, можно читать.
И чем больше автономности у агента, тем эффективнее процесс. Скажем программистам людям же тоже дают задачи, и бывает им доверяют настолько, что не проводят контроль каждой строки.
Я для гарантии качества вчитываюсь в Pull Request который мне делает AI, но в целом это не обязательно - можно задать ему вопросы или отправить другой ИИ не ревью и т.п. При этом что значит вчитываться, я вчитываюсь не очень глубоко, выборочно, я проверю структуру файлов и важные мне моменты, не вчитываюсь во все детали, потому что с 80% вероятностью там всё ок. То есть на ревью у меня уходит 5-10 минут если Pull Request простой и 20-30 минут, если он про какую-то сложную фичу или затрагивает архитектурные правки.
И так как я больше не пишу код вручную, мой фокус теперь на архитектуре, согласованности требований, сборе обратной связи от пользователей и т.п. У меня теперь больше времени просто даже customer development делать в одиночку.
В общем кодинг это не цель, это средство. Я всегда хотел достигать целей которые кодинг помогает реализовать, я никогда не был занят кодингом ради самого кодинга.
Это не исключает при этом, что у меня могут быть очень строгие стандарты к качеству кода и я потихонькую полирую его до совершенства, но теперь не своими руками, а задавая требования, в том числе требования по качеству кода AI агентам.
Новое всегда страшно, но я привык бросаться в неизвестность и испытывать это на себе, поэтому пока кому-то это страшно, я осваиваю новый навык.
А потом появляется статья вот почему я не читаю статьи
Работал у нас в компании один чел. Вроде аналитик. Писал ТЗ. Вот только по такому ТЗ вообще ничего сделать было нельзя. Просто бред с умными словами и терминами использующимися в компании. Интересно было бы посмотреть, что там нагенерил бы ИИ? 🤔😁
Ага, z@lупу на воротник вы себе навайбкодите и на ней повеситесь… если не дано вам код писать, то сидите и невыеживайтесь, вайбкодинг и нейронки вам не помогут
В кабинете стоматолога висела мудрая фраза: "Можно чистить не все зубы, а только те, с которыми жалко расставаться". Для меня она идеально иллюстрирует отношение к ИИ. Нелюбимые проекты, мелкие скриптики, одноразовую всякую фигню - можно делать через ИИ. Ввел задачку, пока там кофе попил - смотришь, и может быть он ее вполне себе решил.
Но любимый проект, важный, отдавать в руки ИИ....
Все что делает ИИ - удешевляет. ИИ пишет код дешевле, чем настоящий программист. И я одно время думал - есть же столько дешевых хостингов типа Hetzner, амазон по сравнению с ними - стоит очень дорого. Но потом понял, что удобства от него - ценнее. И видя биллинг в проекте, по которому работаю, я понимаю, что хостинг там - смешная доля расходов фирмы. Зачем ее сокращать? Удобство, которое дает AWS перекрывает возможную экономию на спичках и потенциальные расходы от проблем с хостингом (коих у AWS бывает меньше, хоть и тоже бывало).
Вот точно так же, если у вас есть важный проект, вы не будете экономить на "зато почти бесплатном" ИИ программисте. Проще платить мясному. Он хотя бы сможет сказать "у вас тут весь проект на прежней версии ...., она через полгода будет уже неподдерживаемая, надо все переделать".
А еще, все что делает программист на самом деле - это уточнение ТЗ. От смутного пожелания заказчика "хочу сайт по продаже холодильников, синенький" доводит до уровня конкретных строчек кода. По шагам. (На первом шаге, например, дополняя в голове подзадачей - "нужна интеграция с платежной системой"). И все это должно быть в согласии с тем, что хочет заказчик (ну и с тем, как это хочет реализовать программист). ИИ по сути сделает то же самое. Что-то у вас может быть спросит, что-то догадается по умолчанию. Но важно понимать, что вся его работа - это НЕ исполнение ТЗ, а его дописывание, уточнение, дополнение. Поэтому, все, что он там "сам догадался" - придется перепроверять. Ну или сказать "ааа, и тааак сойдеет!".
Все примеры которые привел автор не показательны.
На самом деле, в использовании агентов упираешься всегда в две проблемы:
1. Агент плохо пишет логически сложный код и нужно все равно подобные проблемы разгребать самому.
2. Если все становится слишком сложно и нужно изобрести подходящие концепции и новый уровень абстракции, чтобы все упростить, AI не осилит эту задачу хотя-бы потому что он не знает всего о проекте и задаче, и вы не сможете ему вообще все рассказать.
Вторая задача представляется пока нерешаемой.
Первая - кто знает. Во всяком случае Opus здесь очевидно лучше чем Sonet.
Прямо только что в этом убедился. У меня в коде была система для подготовки переводов слов: весь словарь языка делится на 200 порций, слово попадает в порцию в зависимости от его хэша. Дальше, каждая порцияи переводится одним промптом к AI, ответ которого сохраняется в базе под ключом, который вычисляется из хэша всего ответа.
Я спросил у Sonet что будет, если из словаря удалится одно слово и он радостно "оптимизировал" мой код, удалив хэш ответа из ключа ответа AI, "чтобы избежать ненужной перегенерации ответа при удалении одного слова". Ему не пришло в голову подумать что случится, если слово добавлено а не удалено.
Тогда я откатил и повторил тот же запрос у Opus. Он не нашел примемлемых способов оптимизации и оставил в этой части все как есть.
Т.е. выглядит так, что он умнее в плане сложной логики.
А зачем это? Вы на примере лично вашей проблемы ставите под сомнение полезность технологии. Я ещё помню, как на хабре были холивары на тему, что докер не нужОн, это деградация, а использующие его должны быть преданы анафеме ибо это не труЪ.
Челу надо было написать что-то прикладное, он написал, оно работает. Задача выполнена.
Может ли ИИ создать что-то нетривиальное и поддерживаемое? Или это будет что-то типа прототипа, чтобы показать бизнесу идею, а потом выкинуть и переписать нормально?
Может, если ему помочь и направить :)
Жду, не дождусь, когда кто-нибудь уже "навайбкодит" аналог а ну хоть бы 1С и станет долларовым миллиардером как Борис Нуралиев...
Перестаньте пытаться понять, какое место вы займёте в мире, где ИИ стоит на первом месте. Ответ всё тот же, что и всегда: создавайте вещи. Теперь вы можете делать это быстрее, чем когда-либо могли себе представить.
Крутой совет. Осталось выяснить, как и кому их продавать в мире, где точно такие же вещи может "навайбкодить" каждый второй - и дело в шляпе!
В принципе, тогда и продавать не нужно, потому что покупать ничего не нужно. Создавать вещи для себя, стать универсальным мастером-творцом, освободиться от зависимости от специалистов... Это ли не мечта? В фантастике описывали такой универсальный создатель вещей из атомов окружающего мира.
Да понятно, что там под капотом. Костыли, простыни, запросы в циклах, дублирование, маскировка проблем фоллбэками, загрузка всех данных в память, дыры в безопасности.. "Видели-знаем". На реальном большом проекте со сложной логикой постепенно превратится в неподдерживаемую лапшу, которую сам ИИ без 100 грамм перестанет понимать. А он легко путается в сложных связях и тогда начинает галлюционировать, фоллбэчить несуществующие данные, менять несвязанные файлы.. Чинит одно отваливается другое. Недавно с ИИ пытались исправить легаси фичу "слепым методом" из статьи и опус не смог заставить работать, только количество костылей увеличил в 3 раза и сломал другую функциональность. Запутался в эмитах vue компонентов. В итоге переписывали функционал с нуля. Как ни странно, чистый код ИИ понимает гораздо лучше, так что качество кода не только для человека имеет значение.. Если не проходит тест - вместо исправления ошибки может изменить сам тест, чтобы проходил. Тк для ИИ самое главное поставить чек в план любым способом. Лично мой "вайбкодинг" это 2-3 дня на страницу в зависимости от сложности, где большая часть времени - это исправление нагенеренного кода. Да, все равно быстрее чем раньше, но на волшебную кнопку пока не похоже.
Проблема, а может не просто проблема, но контуры грядущей катастрофы в том, что изрядная часть "среднеменеджмента" поражена парадигмой "быстрей быстрей на прод, а то конкуренты я не знаю, что, но что-то сделают и все к ним убегут" и на этой парадигме выстраивают KPI уже в энтерпрайзе и продуктовой разработке которые KPI все сводятся к скорости релиза и сворачиваются в конечном итоге к time-to-market. И вот тут появляется Клод в лапах вкатуна который порождает "Костыли, простыни, запросы в циклах, дублирование, маскировка проблем фоллбэками ", да небезопасно, да не масштабируемо, да не сопровождаемо, но быстро чёрт возьми. Очень быстро. Вроде ничего страшного, но учитывая широту распространения "фигак фигак и в продакшен", и тотальной повсеместности "гибких методик" мутировавших до "разработка архитектуры по историям бабы Зины" может произойти утрата и обесценивание компетенций тех, кто работает по другому, управляет по другому, а Клода использует только как помощника которому нельзя доверять.
Даже не сомневаюсь, что микробизнес переключится на вайбкодинг. Раньше были фрилансеры почти за бесплатно, которые писали дырявый код, теперь вайбкодеры. Ситуация не изменилась.
Интересно было бы взглянуть на итоговый инвойс от Anthropic за месяц таких экспериментов
Теперь-то с такими-то ИИ помощниками вы наконец будете делать кросс-платформенные приложения с компиляцией в нативный код каждой платформы, а не будете пихать везде чертов электрон? Ведь будете же, правда?
Опус 4.5 не фонтан, но брызги есть. Не способен он делать многие задачи! Вы в ахуе от того что для вас и так магией было!!!
Вы заепетесь делать шаблоны этикеток в PDF у вас деньги закончатся
Проект с правами пользователя, вагон багов которые он не понимает и даже если вам показалось что вы сделали вроде что то похожее и работающее, то напишите ему, "эй бро, давай теперь пользователи могут иметь своих пользователей в качестве работников фирмы" 😂 можете сразу 1000+ баксов готовить, а лучше закрывайте проект заранее или привлекайте людей!
Если у вас нет надсмотренности вообще, то вы не реализуете вообще что то серьезное более менее, потому как уже вашего хлама идиотского полный интернет.
Ваш типа проект ложится сразу с более менее нагрузкой пользователей на вашем говноприложении!
Вы не вытяните по деньгам потому что это визуально вы пробовали и "все хорошо", а на самом деле ваше приложение дырявое как ваш восторг! Никакой безопасности там вообще нет😂
Так что призываю сохранять спокойствие всем и не заниматься ! Первым надо прожить жизнь и опыт работы, а аккуратно выбирать партнеров, а не "подешевле"!
Сейчас этих горе-прогеров во фрилансе просто вагон!!! Ломают накуй людям сайты и прячутся потом, потому что конченые дегенераты, как впрочем и те коммерсы которые обращаются к этим "поверившим в себя" которым нужно кредит возвратить за этот опус😂
@moderatorобратите внмание, пожалуйста, на чрезмерное использование обсценной лексики, пусть и немного завуалированной.
Мне во всех этих историях о волшебном клауде нравится как его хвалят вроде:
"С Opus 4.5 я пока в эту стену не упирался — Opus всегда сам находит проблему и чинит собственные баги."
А гениальная нейросеть не может не совершать ошибки? Ну или хотя бы научиться не повторять их из раза в раз?
Я сайт так написал с нуля с помощью ИИ. без фреймвопков и cms. FRONT, BACK.Код чистейший,быстрый. Админку сделал под себя. Быстро,кастомно. В код лез тогда,когда нужно было внести локальные изменения. В некоторые модули до сих пор не забирался и не планирую. Но деталь. Надо уметь писать и без ИИ. Если знаешь,что делаешь,то с ИИ, скорость разработки увеличивается в разы. И правильно где то читал,да и здесь что то подобное комментировали, что ещё пару лет назад надо было шариться по stackoverflow,сейчас я туда уже наверное год не заглядываю.
Все эти проекты это уровень pet и фриланса. Но если вернуться в суровый ентерпрайз, то программист не просто писатель кода, он должен хотябы на базовом уровне понимать бизнес-задачу и стандарты проекта. И донести ему это нужно один раз. С LLM явно или скрыто это необходимо скармливать при каждом запросе, что с увеличением сложности проекта удорожает каждое такое изменение в геометрической прогрессии.
И второй момент, который почему-то упорно умалчивается - рост количества ИИ контента неизбежно приведет к существенной деградации моделей.
А если посмотреть на динамику?
три года назад: да ИИ даже простейшую функцию на пару строк не может написать
два года назад: да ИИ даже более-менее сложную функцию меньше сотни строк написать не может
год назад: да ии может написать небольшой модуль, но проект точно не сможет
сегодня: пет-проект ИИ написать может, но крупные проекты в энтерпрайзе нет
еще через год-два-три-четыре?
еще через год-два-три-четыре?
Один раз за все эти годы? Так люди гораздо чаще за это же время базы дропали и иногда это даже на публику попадало.
о, прога для конвертации изображений как раз нужна была - скачала. Спасибо автору.. ну и Клоду тоже спасибо конечно =) Моментально сейчас разгребла кучу тяжеловесящих картинок
Объясните мне, пожалуйста, как вы работаете с моделями при участии в разработке реальных коммерческих проектов? Как правило, все они под NDA, т.о. нельзя пользоваться сторонними инструментами, куда потенциально может утечь кодовая база. Можно развернуть нужную модель локально, но для этого нужно мощное железо. Неужели у всех таких мощные компы? Или проекты не под NDA?
Настоящий вопрос — это качество кода. Если я не понимаю, как он устроен, откуда мне знать, нет ли там дублирования, мёртвого кода или плохих паттернов? Раньше я на этом зацикливался. Сейчас меня это волнует гораздо меньше, потому что я искренне не уверен, что человеку вообще нужно читать этот код. .
Вот теперь понятно откуда у нас в ДНК столько "мусорного кода". Нас писал ИИ!
Всë так, думаю, что через лет 5 ии почти заменит программистов. Года через 2-3 вкат окончательно умрëт
И по-прежнему ни одного примера поддержки старого легаси-кода какого-нибудь древнего проекта без документации... Вот когда ИИ сделает это, тогда я поверю, что он что-то может
В статье описываются максимально базовые вещи, которые и раньше с лихвой делались нейронкой. "Революция" только в автономности. Нейронка всё равно не понимает, не осознаёт то, что она пишет, и это - главная проблема.
Вот у меня прекрасный пример галлюцинаций нейронки есть. Можете особо не вникать, но я постараюсь максимально кратко объяснить. Мы разрабатываем сервис, связанный с логистикой перевозок. Мой коллега по проекту попросил ИИ написать код для просчета сложных маршрутов (маршруты из 2-х сегментов, с промежуточной точкой). Конкретно - нужно было написать запросы к БД через Sqlalchemy (т.е. нужен SELF JOIN). Нейронка вместо того, чтобы честно этот SELF JOIN написать, взяла и просто поменяла тип маршрута в базовом запросе. Всё работало! Без единой ошибки. Но данные были некорректны. Всё потому, что нейронка не поняла, что надо сделать
В примере проблема, безусловно, не в нейронке, а в способе её использования. Человек просто не проверил результат. Но этот пример отлично доказывает, что нейронка может легко не понять, и без единой ошибки в консоли сдать "готовый" проект, который не будет правильно работать. Если бы у нас были тесты, нейронка так же неправильно могла бы их написать из-за отсутствия осознания задачи. Именно понимание цели делает человеческий код надёжнее. И пока нейронка не сможет осознавать то, что она делает, она никогда не заменит человека. Не всё можно покрыть автотестами. Иногда нужно реальное понимание задачи
Сам скептически всегда относился ко всему этому вайбкодингу, пока не попробовал с нормальной системой индексирования кода типо как Cursor и моделью клауди. Да это херня реально сломанная и максимально близко похоже к тому что раньше в фильмах показывали про ИИ которые сами анализируют, думают и делают. Единственно что за это есть цена конечно и не малая, на норм проекты люди буквально тысячи евро сливают на токены в месяц и опус полностью заменяет инженера программиста, тут конечно ещё вопрос что лучше опус или нанять прогера за 5к евро в месяц. Если эта херня не деградирует то лет через десять может заменить многих программеров, хотя опять таки все упирается в цену. Люди пишут что минус типо ИИ может нагавнокодить, вы не поверите но и человек программист может сделать тоже самое, поэтому конечно за этим нужен контроль и понимание как все работает, просто роль твоя уже смещается в сторону ревизора кода, а не программиста. А если вы просто вайбкодер у которого ИИ там чет делает ты не знаешь что просто результат готовый используешь, то да такое думаю вымрет скоро, так как видно что модель монетизации меняется с продажи запросов на тарификацию токены/$, и конечно такие вайбкодеры просто бабло все сольют и на этом все.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Claude Opus 4.5 и конец привычной разработки