Comments 168
Вот почему я больше не читаю код
Да, хреново когда не знал, да еще и забыл...
Вот живой пример из недавнего. Чувак с гордостью представил свою разработку, над которой он, по его словам, работал больше года. Только репозиторий со всей историей был создан буквально на днях. Старательно вычистил все демаскирующие Клода вещи, но кода в мешке не утаишь.
А потом народ не поленился и накопал под сотню серьезнейших проблем в этом коде слопе.
Беда в том, что таких уslёпков будет все больше. Разумеется, проблема не в ИИ и не в Клоде. Это замечательный инструмент, если уметь им пользоваться. Проблема в людях, которые, вайбкодь@не_читай и херак-херак-в-продакшн, притом что ни в том ни в том не разбираются от слова совсем.
таких уslёпков будет все больше
не в защиту вайбкода, но ради справедливости ради.
В мире существуют миллионы приложений созданных методом копипаста со Stackoverflow и публичных репозиториев (написанных человеком без участия ИИ) Неоптимизированные библиотеки, фреймворки ради фреймворков, издевательское потребление вычислительных ресурсов. Программисты это оправдывали тем, что их время слишком дорогое, чтобы писать код идеально, потому что улучшать можно бесконечно. Вычислительные мощности растут, а мы концентрируемся на фишках и архитектуре. Мы программисты, а не машинистки. Но почему-то ни для кого это не является проблемой.
Cколько серверов настроено скриптами скачанных с github написанные неизвестно кем и запущенных от root . И это опять ни для кого не является проблемой.
Так что ИИ хрючево не является проблемой. По крайней мере я не слышу возмущения от Paramount, что ИИ заберёт у них работу.
Вот живой пример из недавнего
Не факт, что некто умнее/опытнее не разнесёт ваш код написанный руками, выложив вы его в открытый доступ. Неизвестны ни квалификация автора ни квалификация проверяющего. Но такой код-ревью определенно пойдёт на пользу.
В мире существуют миллионы приложений созданных методом копипаста со Stackoverflow и публичных репозиториев
Порог входа даже в такой копипасте заключается в том, что во многих случаях "скопипасченый" код не работает и его нужно немного причесать, либо заглянуть в ветку комментариев и посмотреть там прочие предложенные варианты, которые подойдут именно вам.
+ надо знать куда вставлять и как. Сейчас нету даже такого сдерживающего фактора, и к этим "миллионам" еще "миллиард" на подходе))
Не факт, что некто умнее/опытнее не разнесёт ваш код написанный руками
так речь не только в "разносе кода"
почти все вещатели успешного успеха - либо пустое репо имеют, либо просто созданное "15 минут назад". Побеждают в международных ИИ хакатонах, о которых кроме одной группы в ВК на 200 человек никто не знает ну и так далее... Список их ИТ-регалий бесконечен. А по факту, насмотрелись на "больших дядек" в ИТ, и захотели стать такими же, и теперь каждый стал архитектором и надулся как ИИндюк)
Сейчас нету даже такого сдерживающего фактора, и к этим "миллионам" еще "миллиард" на подходе
Сдерживающий фактор чего? No/Low-Code платформы как-то обрушили ИТ-отрасль? Как и с ИИ, домохозяйки и региональные ИП вкатились и для своих потребностей использовали без приобретения всяких Битрикс за тонны (зачастую неоправданных) денег или колупания в Joomla. Пока никто вайбкодеров на работу в битехи не берёт. Бигтехи сами внедряют ИИ под присмотром труЪ Senior software architect. Если вам придётся конкурировать с вайбкодером на рынке труда, ну что ж... когда-то и лошадь была транспортом, а сейчас развлечение на выходные.
Список их ИТ-регалий бесконечен. А по факту, насмотрелись на "больших дядек"
Проблема-то в чём? В том, что при появлении новой ниши в неё стараются пролезть все кому не лень? Или то, что у вас об этой нише иное представление.
ушлепок пока здесь только один с повышенным ЧСВ
Некоторые уже начинают запрещать контрибьютить ии-код. В репозитории fastapi чуваки прямо в сontributing.md прописали, что будут банить авторов, код, PR или комменты которых похожи на слоп.
Сначала "я не пишу код".
Потом "я больше не читаю код".
Дальше будет "я не смотрю, как этот код работает".
И в финале "мне больше не платят зарплату".
Не, на а чё? Вполне естественный процесс...
Сегодня ты не читаешь код, а завтра твоя программа, сгенерённая ИИ для постов картинок ИИ с описаниями от ИИ постит в Фейсбук детскую порнографию с прекрасным описанием, всё как ты и просил, и вдруг ты слышишь требовательный стук в дверь. Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Иногда читать может быть нужно, а иногда достаточно хорошо настроенного 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),
}
}
}В утрированном примере с конечным тех заданием сразу - да)
На деле проверки были не рядом а между ними были дополнительные шаги, которые могли привести к попаданию в другой диапазон, и нет - написать вот так красиво в принципе не получилось бы т.к. для вычисления точного значения нужно было лезть во внешние сервисы, а лезть в них всегда было слишком дорого по производительности, и понятность того, нужно это делать или нет была частью постпроцессинга.
Можно было бы заменить это на рекурсивной вызов функции с проверкой диапазонов, но тогда туда помимо прочего надо было бы накинуть вагон аргументов, вычисляемых на первом этапе, чтобы не делать это повторно, и при этом все они были бы необязательные - даже не знаю лучше бы стало или ещё хуже)
Но не переживай, это же профиль твоей жены, тебе ничего не грозит.
Ахахахаха. Супер! :)
Пробовали когда-то через ту же нано банану генерить какое-либо порно? Как успехи?
Один нюанс: все это работает, пока антропик и прочие демпигуют, работают в минус и прожигают шальное бабло инвесторов. На чужом горбу в рай. Впрочем, ничего нового.
Но есть и обратная сторона - триллион на AI уже сожжен (буквально, в гигаватт-часах), чипы распаяны, ДЦ уже построены, модели уже обучены.
5% нынешней окупаемости отрасли смогут покрыть только инференс, даже в случае банкроства и распродажи ДЦ с долговых аукционов.
Т.е. в каждый момент времени можно ожидать, что уже достигнугнутый моделями уровень ниже не упадет даже с наступлением полномасштабного кризиса отрасли (на таком масштабе пузыря он неизбежно совпадет с общим финансовым кризисом).
Следствие - те, кого модели могут оставить без работы уже сейчас, они оставят без работы и в случае кризиса ИИ отрасли. Банкроство ИИ стартапов не возродит профессию переводчика текстов, например.
Исторические аналогии - банкроство железных дорог, как стартапов 19 века, не остановило железнодорожное сообщение. Построенными дорогами все равно пользовались. За исключением совсем экстремальных случаев ЖД веток в никуда.
Речь про цену данного удовольствия. Все эти пророки "новой эры" любят повторять, что "как раньше уже не будет". Хорошо, не будет. Но вся бравада строится исключительно на том, что теперь всегда будет так, как сейчас. То есть антропик теперь во веки вечные будет толкать им свой товар по 100 баксов в месяц. А если по 1000 баксов? А по 5000? Уже за 1000 баксов болтовни будет на пару порядков меньше. Какой-то вселенский закон запрещает такой исход событий? Всегда на рынке будет такая же анархия и конкуренция как сейчас? Это тоже каким-то законом предопределено?
Смотрите хотя бы опыт Яндекс такси. Сначала тоже кипятком ссали от низких цен.
Мне кажется, вы привели Я.Т. как пример "не в ту сторону".
ЯТ замечательно заменил бомбил и тогда и сейчас. Вы вообще часто на дороге руку поднимаете? Да, сказочно дешевый период закончился, начался просто дешевый. Он по прежнему дешевый, дешевле, чем бомбила.
А еще, мне кажется, AI отлично офшорится. Никто не обязывает иметь ИИшный дата-центр через квартал - там все равно скорости медленные. Можно даже правдоподобно вообразить AI-датацентры за северным полярным кругом - там проще с охлаждением и проще ставить АЭС.
Никто не обязывает иметь ИИшный дата-центр через квартал - там все равно скорости медленные. Можно даже правдоподобно вообразить AI-датацентры за северным полярным кругом - там проще с охлаждением и проще ставить АЭС.
А потом решаешь зохавать какой-нибудь, например, полуостров — и обаньки...
На полуострове нет термальных источников. Надо взять Исландию в аренду. Там незамерзающая, но прохладная вода со всех сторон, и термальные источники. "Халявная", круглогодично-ровная генерация.
Не нужно ничего брать в аренду, просто нужно быть Президентом одной очень мощной страны, и тогда объявляешь, что вокруг нужной тебе земли крутятся эсминцы и подлодки других стран, а поэтому эта земля должна стать твоей. И все, никакой аренды.
В чем здесь логика, вопрос не ко мне, но судя по всему это работает 😂
начался просто дешевый
Мне нужно было из Северного в Южное бутово доехать - 600-800 рублей днем, 1200-1500 рублей в час ночи. Это 10 минут езды, 6 километров.
Ят монополист. Где вы видели чтобы в монополиях без контроля со стороны что-то было дешево?
Яндекс не поднял цены настолько, что бы маленькие таксопарки опять смогли зарабатывать. Антропик не поднимет настолько, что бы найм живого программиста, пишущего руками, стал бы рентабельным.
Но выжать максимум, подняв цены до 95% от цены программиста они конечно постараются в будущем. Итог будет зависеть от конкуренции с китайцами, в частности. Вам выше верно написали, инференс дешёвый, даже если ни один инвестор больше не даст ни рубля на обучение новых моделей, текущие модели можно продавать в плюс, поэтому они никуда не денутся.
И каждые 5% эффективности будут усугублять положение, а уж 5% там без сомнения есть где выжать (мое личное мнение - еще 100 раз по 5% точно возможно)
Антропик не поднимет настолько, что бы найм живого программиста, пишущего руками, стал бы рентабельным.
Я вообще-то на другой тезис отвечаю. Текущий modus operandi автора это "я код не читаю, иишка всё сама, если что - попрошу переписать". Так вот такой благодати будет тем меньше, чем ближе цена подписки к справедливой и рентабельной.
Отрицать удобство Я.Такси просто глупо
тут не так давно был всплеск статей (вроде и на хабре тоже было что-то) о том, что ии-ускорители выходят из строя быстрее, чем успевают окупиться, так что ДЦ сами по себе могут быть не сильно ликвидным активом.
А что *ять, если нет? (с)
Когда вышел первый iPhone -- брусок с полностью стеклянным экраном, тоже "здравый смысл" подсказывал, что на рынке телефонов ему делать нечего и Apple всё.
доведут со временем до нормальной готовности, сейчас просто потогонка и не успевают скорее всего железо отладить
Да пфф, зависимость от энергопотребления очень и очень нелинейная. Можно снизить энергопотребление процентов на 25% потеряв 5% производительности. А это сразу меньше температура и меньше деградация чипов.
Откуда информация про 5 процентов? И от чего эти 5 процентов? От бесплатных подписок? Платных? Подписок за 100-200 баксов? Enterprise подписок? API в токенах?
Тут вот в цифрах написано как это выглядит.
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";
Подобные вещи встречаются сплошь и рядом.
Простите, я из чистого любопытства, не обладая никаким знанием предметной области, и посредственным знанием (прикладным) 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 и множества других.
Синтетические тесты тут ни как не помогут. Что вы хотите в них анализировать? Как выстроите их, по какому критерию? Просто частоты сдвинулись или нет? В голосе форманты имеют обертоны, и если вы просто сдвинули какую то частоту то это не будет согласовываться например с ними.
А вы уверены, что код верный, а то три нейросети (Claude Opus 4.5 thinking, Google Gemini 3 Pro, ChatGPT 5.2 Thinking) дружно его критикуют? Они могут ошибаться, но как правило всё-таки находят узкие места. Я не разбираюсь ни в этой библиотеке, ни в Python и не хочу быть испорченным телефоном, но всё же рекомендовал бы спросить что они думают о коде и почитать, вполне возможно что выявятся скрытые проблемы. Например, они утверждают, что это некорректный сдвиг, что будут артефакты, что есть неэффективность по производительности. Когда разные модели солидарны, это как правило признак какой-то проблемы.
Praat это самая популярная и эффективная библиотека при работе с голосом. Все LLM ее знают и все равно галлюцинируют на ней часто обращаясь к тому чего нет. Как уже было сказано выше, да она правильная, так как использовал ее при изменении голоса.
Ниже пример, где также используется эта функция. Я прекрасно знаю что на все это пишут LLM, проблема в том, что они не могут не писать, даже там где имеют проблемные места.
Я использую LLM, просто у них есть границы применимости.
Ну, я вот слышу металлизированный робоголос, о котором одна из моделей и писала, как о следствии именно такого, не вполне корректного преобразования и предлагала другое. Звук явно не очень естественный. Но, ещё раз, мне сложно оценивать, я в теме не разбираюсь. Вполне возможно галлюцинации сразу трёх моделей.
Что вам не нужно: имена переменных, форматирование, комментарии для людей или паттерны, придуманные только для того, чтобы пощадить ваш мозг.
Ну-ну. То есть, вы утверждаете, что ИИ не нужен читабельный код? Вы серьезно думаете, что если у вас код без комметариев, без нормальной архитектуры, с одной гигантской функцией 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
Если бы это был баг. Это просто warning. Вставлять костыль чтоб зафиксить warning - это бред.
И я бы согласился если бы там был паралельный PR в gramJS, и TODO: вроде "удалить после корректного фикса" со ссылкой на него.
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 настроенной для поддержки команды разработки из ИИ и людей - это работает буквально как часы или хорошо выстроенный промышленный процесс.
А $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 команда в ней частично реализованы функции мониторинга, но мне пока не нравится эффективность такого подхода. Пока что на этапе тестирования текущего варианта, я считаю, достаточно, а дальше посмотрим как пойдёт. Для начала мне бы понять что для реальных пользователей является наиболее удобным форматом взаимодействия. Плюс есть ещё над чем работать чтобы улучшать стабильность и качество текущего решения.
Пост вроде должен был быть про 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. Он не нашел примемлемых способов оптимизации и оставил в этой части все как есть.
Т.е. выглядит так, что он умнее в плане сложной логики.
А зачем это? Вы на примере лично вашей проблемы ставите под сомнение полезность технологии. Я ещё помню, как на хабре были холивары на тему, что докер не нужОн, это деградация, а использующие его должны быть преданы анафеме ибо это не труЪ.
Челу надо было написать что-то прикладное, он написал, оно работает. Задача выполнена.
Может ли ИИ создать что-то нетривиальное и поддерживаемое? Или это будет что-то типа прототипа, чтобы показать бизнесу идею, а потом выкинуть и переписать нормально?
Перестаньте пытаться понять, какое место вы займёте в мире, где ИИ стоит на первом месте. Ответ всё тот же, что и всегда: создавайте вещи. Теперь вы можете делать это быстрее, чем когда-либо могли себе представить.
Крутой совет. Осталось выяснить, как и кому их продавать в мире, где точно такие же вещи может "навайбкодить" каждый второй - и дело в шляпе!
Да понятно, что там под капотом. Костыли, простыни, запросы в циклах, дублирование, маскировка проблем фоллбэками, загрузка всех данных в память, дыры в безопасности.. "Видели-знаем". На реальном большом проекте со сложной логикой постепенно превратится в неподдерживаемую лапшу, которую сам ИИ без 100 грамм перестанет понимать. А он легко путается в сложных связях и тогда начинает галлюционировать, фоллбэчить несуществующие данные, менять несвязанные файлы.. Чинит одно отваливается другое. Недавно с ИИ пытались исправить легаси фичу "слепым методом" из статьи и опус не смог заставить работать, только количество костылей увеличил в 3 раза и сломал другую функциональность. Запутался в эмитах vue компонентов. В итоге переписывали функционал с нуля. Как ни странно, чистый код ИИ понимает гораздо лучше, так что качество кода не только для человека имеет значение.. Если не проходит тест - вместо исправления ошибки может изменить сам тест, чтобы проходил. Тк для ИИ самое главное поставить чек в план любым способом. Лично мой "вайбкодинг" это 2-3 дня на страницу в зависимости от сложности, где большая часть времени - это исправление нагенеренного кода. Да, все равно быстрее чем раньше, но на волшебную кнопку пока не похоже.
Проблема, а может не просто проблема, но контуры грядущей катастрофы в том, что изрядная часть "среднеменеджмента" поражена парадигмой "быстрей быстрей на прод, а то конкуренты я не знаю, что, но что-то сделают и все к ним убегут" и на этой парадигме выстраивают KPI уже в энтерпрайзе и продуктовой разработке которые KPI все сводятся к скорости релиза и сворачиваются в конечном итоге к time-to-market. И вот тут появляется Клод в лапах вкатуна который порождает "Костыли, простыни, запросы в циклах, дублирование, маскировка проблем фоллбэками ", да небезопасно, да не масштабируемо, да не сопровождаемо, но быстро чёрт возьми. Очень быстро. Вроде ничего страшного, но учитывая широту распространения "фигак фигак и в продакшен", и тотальной повсеместности "гибких методик" мутировавших до "разработка архитектуры по историям бабы Зины" может произойти утрата и обесценивание компетенций тех, кто работает по другому, управляет по другому, а Клода использует только как помощника которому нельзя доверять.
Интересно было бы взглянуть на итоговый инвойс от Anthropic за месяц таких экспериментов
Теперь-то с такими-то ИИ помощниками вы наконец будете делать кросс-платформенные приложения с компиляцией в нативный код каждой платформы, а не будете пихать везде чертов электрон? Ведь будете же, правда?
Опус 4.5 не фонтан, но брызги есть. Не способен он делать многие задачи! Вы в ахуе от того что для вас и так магией было!!!
Вы заепетесь делать шаблоны этикеток в PDF у вас деньги закончатся
Проект с правами пользователя, вагон багов которые он не понимает и даже если вам показалось что вы сделали вроде что то похожее и работающее, то напишите ему, "эй бро, давай теперь пользователи могут иметь своих пользователей в качестве работников фирмы" 😂 можете сразу 1000+ баксов готовить, а лучше закрывайте проект заранее или привлекайте людей!
Если у вас нет надсмотренности вообще, то вы не реализуете вообще что то серьезное более менее, потому как уже вашего хлама идиотского полный интернет.
Ваш типа проект ложится сразу с более менее нагрузкой пользователей на вашем говноприложении!
Вы не вытяните по деньгам потому что это визуально вы пробовали и "все хорошо", а на самом деле ваше приложение дырявое как ваш восторг! Никакой безопасности там вообще нет😂
Так что призываю сохранять спокойствие всем и не заниматься ! Первым надо прожить жизнь и опыт работы, а аккуратно выбирать партнеров, а не "подешевле"!
Сейчас этих горе-прогеров во фрилансе просто вагон!!! Ломают накуй людям сайты и прячутся потом, потому что конченые дегенераты, как впрочем и те коммерсы которые обращаются к этим "поверившим в себя" которым нужно кредит возвратить за этот опус😂
Мне во всех этих историях о волшебном клауде нравится как его хвалят вроде:
"С Opus 4.5 я пока в эту стену не упирался — Opus всегда сам находит проблему и чинит собственные баги."
А гениальная нейросеть не может не совершать ошибки? Ну или хотя бы научиться не повторять их из раза в раз?
Я сайт так написал с нуля с помощью ИИ. без фреймвопков и cms. FRONT, BACK.Код чистейший,быстрый. Админку сделал под себя. Быстро,кастомно. В код лез тогда,когда нужно было внести локальные изменения. В некоторые модули до сих пор не забирался и не планирую. Но деталь. Надо уметь писать и без ИИ. Если знаешь,что делаешь,то с ИИ, скорость разработки увеличивается в разы. И правильно где то читал,да и здесь что то подобное комментировали, что ещё пару лет назад надо было шариться по stackoverflow,сейчас я туда уже наверное год не заглядываю.
Все эти проекты это уровень pet и фриланса. Но если вернуться в суровый ентерпрайз, то программист не просто писатель кода, он должен хотябы на базовом уровне понимать бизнес-задачу и стандарты проекта. И донести ему это нужно один раз. С LLM явно или скрыто это необходимо скармливать при каждом запросе, что с увеличением сложности проекта удорожает каждое такое изменение в геометрической прогрессии.
И второй момент, который почему-то упорно умалчивается - рост количества ИИ контента неизбежно приведет к существенной деградации моделей.
о, прога для конвертации изображений как раз нужна была - скачала. Спасибо автору.. ну и Клоду тоже спасибо конечно =) Моментально сейчас разгребла кучу тяжеловесящих картинок
Claude Opus 4.5 и конец привычной разработки