Обновить

Комментарии 63

>но пока не переломный момент

да уже переломный. Пусть в меня кинет камнем тот, кому LLM ни разу не смогло наreviewить оптимизацию. Ну типа, ты ему кидаешь SQL или NOSQL запрос, а он в ответ: "слушай, чувак, прям нечего предложить"

Я для оптимизации код обычно не ИИ кидаю, а обкладываю со всех сторон метриками и выкатываю на нагрузочный стенд. И там уже сравниваю между собой ряд гипотез по оптимизации. Мне кажется, что этот подход более эффективен, чем ИИ галлюцинации.

Вам про Фому, а вы про Ерему. ИИ это и есть (еще один) источник гипотез по оптимизации. А дальше какие-то и так очевидно полезны или вредны, а какие-то надо вот выкатывать на нагрузочный стенд и далее по вашему тексту.

Гипотез много не бывает.

А как же «один дурак за пять минут может задать столько вопросов, что и сто мудрецов за сто лет не ответят»?

Ну, если у специалиста не получается выдвинуть гипотезу, то почему бы и не погуглить или поИИшить? Другой вопрос, очень хотелось бы, чтобы специалист понимал суть найденный таким образом гипотезы, и осмысленно принимал решение о необходимости её проверки.

Ну, если у специалиста не получается выдвинуть гипотезу, то

..встаёт вопрос — «а он точно специалист?»

@milkyway044: LLM не делает вас тупым. Она просто убирает иллюзию, что вы были умным.

Ну вот я 25 лет код пишу. Последние 20 лет пишу на Java. И все эти 25 лет мне приходится непрерывно учиться. Потому что индустрия стремительно эволюционирует, и, тут как в сказке про Алису в стране чудес - нужно очень быстро бежать вперёд, чтобы просто оставаться на месте. И да, у меня все эти 25 лет регулярно возникают ситуации, когда я чего-то не знаю, и вынужден гуглить. Точно ли я специалист?

PS

Лично я ИИ воспринимаю как следующую ступень эволюции поиска информации. Раньше информацию передавали и уст в уста. Потом появились книги. Потом интернет. Теперь вот ИИ выскочил. Просто у меня появился ещё один один инструмент для поиска информации.

PPS

Ну и лично про себя скажу, что мне ИИ пока ничем не помогает. На том уровне, на котором ИИ ответы выдаёт я и сам всё знаю. А на том уровне, на котором у меня проблемы возникают, ИИ не в состоянии работать.

PPPS

Ну а хайп с "вайб кодингом" в виде, что можно ничего не понимать и тупо писать промпты - это не более чем жёлтый пиар для выкачивания денег из инвесторов. Этот подход работает только на примитивных задачах. В серьёзной разработке нужен специалист. Ну а пользуется ли он ИИ, гуглом, книгами или устным народными творчеством - это его дело. Главное, чтобы понимал, что и зачем делает. И был готов развивать проект в долгосрочной перспективе.

Ну вот я 25 лет код пишу.

Ну вот я тоже (только уже 35).

И все эти 25 лет мне приходится непрерывно учиться.

Именно. «В геометрии нет царских путей».

И да, у меня все эти 25 лет регулярно возникают ситуации, когда я чего‑то не знаю, и вынужден гуглить. Точно ли я специалист?

А что, разве у Вас возникали проблемы выдвинуть гипотезу? Вы её выдвигали — и лезли гуглить, дабы проверить, потому как раньше правильных ответов было больше — а сейчас нейрослоп отакуэ.

Лично я ИИ воспринимаю как следующую ступень эволюции поиска информации. Раньше информацию передавали и уст в уста. Потом появились книги. Потом интернет. Теперь вот ИИ выскочил. Просто у меня появился ещё один один инструмент для поиска информации.

Вот только проблемы «а в книге оно точно правильно, или аффтар ерунду какую‑то написал?» раньше не было. (Я сейчас не про всевозможные священные книги.)

Ну и лично про себя скажу, что мне ИИ пока ничем не помогает. На том уровне, на котором ИИ ответы выдаёт я и сам всё знаю. А на том уровне, на котором у меня проблемы возникают, ИИ не в состоянии работать.

О том и речь — мы с Вами из второй категории.

Все программисты в мире делятся на две категории:
— Те, кто считает, что ChatGPT кодит на порядок лучше их;
— Те, кто считает, что ChatGPT кодит на порядок хуже их.
И те, и другие абсолютно правы.

Ну а пользуется ли он ИИ, гуглом, книгами или устным народными творчеством — это его дело. Главное, чтобы понимал,

..где какая вероятность гонева.

Вот только проблемы «а в книге оно точно правильно, или аффтар ерунду какую‑то написал?» раньше не было.

Было. Всегда. Вспоминаем про 8 ног у мухи. Что характерно, про то, что так полагал Аристотель, тоже вроде брехня. Это вроде появилось только в переводах Аристотеля, вроде даже в переаодах переводов.

(Я сейчас не про всевозможные священные книги.)

А вот священные книги как раз обычно дают исчерпывающе верное представление о каноне веры тех, для кого эти книги священные, ибо ошибки и иные разночтения либо ксрались, либо приводили к появлению нового вероисповедания.

НЛО прилетело и опубликовало эту надпись здесь

Вовсе не на две категории. Мы вместе с "архитектором" в Клауд код придумываем архитектору, предлагаем идеи и ищем лучшее решение. Порой косячит он, порой я. Когда он - я рад, что я это вижу и могу контролировать. Когда я - я рад, что у меня теперь коллега, что страхует. Но разумеется, чем умнее tool, тем более вероятен ее хитрый сбой

Ви знаете, резиновый утёнок значительно дешевле при меньшем углеродном следе.

Бежать все быстрее, что бы отставать не так быстро. Где то уже на пределе возможностей человека как вида. Мы уже в стрессовой яме и стрессовом техдолге неразгребном.

Мы уже в стрессовой яме

«Отучаемся говорить за всю сеть» ©

>а он точно специалист

ну я например работаю активно с 3 разными субд (в разных проектах), mongo, elasticsearch, neo4j очевидно что я не могу быть спецом во всех трёх. они ещё и обновляются с лютой скоростью.

один в каждой бочке затычка wesha всё успевает. правда анонимно и без пруфов. ну ок.

что я не могу хочу быть спецом во всех трёх

There, FTFY.

в каждой бочке затычка

«А я буду, буду трындеть!» ©

Как-то в компании, занимающейся ММО-игрой, для серверных разработчиков проводили тренинг как искать медленный код. Причём тренировались мы на реальном коде сервера. В итоге: нашли неэффективный код, ускорили его в 4 раза (+300%, однако!). А потом посчитали, что в абсолютных величинах выигрыш - примерно 1 секунда машинного времени в сутки на весь сервер целиком. То есть смысла выкатывать оптимизацию нет - на пропихивание её через весь цикл публикации ушло бы куда больше времени, чем она вообще могла бы сэкономить.

Мораль: для хорошей оптимизации нужно не только и не столько код смотреть, сколько весь продукт целиком. Желательно ещё и в контексте работы организации.

Для 98% проектов мой подход и вправду не имеет смысла. Но на рынке есть примерно 2% высоконагруженных проектов, с жёсткими требованиями по времени отклика. И это не игрушки. Там оптимизация экономит миллионы рублей. И там эффективен научный подход.

Этот научный подход - когда рассматриваются вся производственная система/цепочка в целом, и оптимизируется не всё подряд, то что на поверхности, или не эффективно (как в производственной системе компании Тойота), а ищутся "бутылочные горлышки" ограничивающие производительность, и оптимизируются только они - называется Теория ограничений.

Кому интересно можно почитать книгу Элияху Голдратта "Цель".

Да - так и есть. И именно для этого я выкатываю ВСЮ систему на стенд, даю нагрузку сопоставимую с продом, с помощью метрик ищу бутылочные горлышки, а потом на том же стенде проверяю гипотезы по оптимизации бутылочных горлышек. Что я делаю не так?

В моем понимании стенды обычно не сопоставимы по аппаратным характеристикам с продом, каким образом вы даете нагрузку сопоставимую с продом? Вычисляете относительную разницу между стендами?

Вот тут не имею права говорить конкретные цифры. NDA. Но, грубо говоря, на стенд даю нагрузку кратно меньшую, чем на прод. Подбираю примерно так, чтобы на одну виртуалку на стенде приходилась та же самая нагрузка, что и на одну виртуалку на проде.

Ну и плюс поиск максимума. Плавно увеличиваю нагрузку на стенд так, что нагрузка на одну виртуалку в разы больше, чем на проде. И увеличиваю до тех пор, пока стенд не развалится. Очень помогает заранее подготовиться к стрессовым сценариям на проде.

ALE-Agent же придумал эвристику "виртуальной мощности", которая оценивает еще не запущенные машины так, будто они уже работают

Да всё так, просто как я понимаю, его подход не слишком отличается

Хороший тренинг и конкурсы интересные! Неэффективный код, я так понимаю, искали глазами, а не профайлером?

В принципе "обкладываю метриками" в 2026 уж звучит странно учитывая существование opentelemetry и ему подобного, которыми зачастую обложен весь прод по умолчанию и которые сигналят сразу в дашборды при наличии проблем.

Более того, нейронки прекрасно читают эти данные и делают неплохой анализ на их основе вплоть до поиска проблем в коде на основе варнингов общей системы.

Opentelemetry вам подскажет что из Москвы во Владивосток вы слишком долго едете. А "детали" уровнем ниже он вам не подскажет.

Более того, нейронки прекрасно читают эти данные и делают неплохой анализ на их основе вплоть до поиска проблем в коде на основе варнингов общей системы.

Если речь идёт про "стандартные" проекты и стандартные проблемы - то да, там нейронка может что то и изобразит. Но там чаще всего и оптимизировать что то смысла нет. А если речь идёт про те 2% высоконагруженные проектов, о котрых пишу я - то нет. Там вам нейронка ничем не поможет. Над такими системами работают серьёзные специалисты. Стандартные проблемы они быстро фиксят сами. Больше всего боли вызывают нестандартные проблемы, где ИИ бесполезен.

Вопрос управления рисками. Начиная с какого то уровня нет плохих/хороших решений, есть решение которое может стать неподходящим в случае реализации сценария 1 или отличным в случае нереализации. Написали Вы 2 года назад нагруженную систему, которая требует объемов ОЗУ, но работает быстро, а цена на память прыгнула (эти риски непросчитываемы), Вы ж не стали от этого плохим программистом. На каком то уровне исчезает вопрос: "как лучше?", возникает "какие риски мы на себя готовы взять?" и их стоимость. ИИ не заберет на себя риски и сопутствуюшие убытки, ей все равно.

Да, риски и долгосрочная стратегия развития проекта это вообще отдельная тема. В разработке важно не то, с какой скоростью мы бежим а то, в каком направлении мы бежим. Иначе внезапно выясняется, что мы очень быстро бегаем по кругу. И тут ИИ совершенно бесполезен. Причём тут он бесполезен не только на тех 2% нагруженных проектах, про которые я говорил, но и на стандартных проектах.

Нейронке не надо что то изображать, она дополнительный слой анализа за счет своего "багажа знаний" и "консультант". Использовать даже последние модели для багофиксов прода в высоконагруженных системах я бы лично не стал :) А вот накидать ей гору метрик и архитектуру проекта с просьбой анализа - вполне ок.

Вот по поводу архитектуры проекта... Ох, лучше не надо :) Черевато.

Постараюсь объяснить свое мнение о том, что не стоит отдавать проектирование архитектуры ИИ.

Вот представьте, что вы решили построить себе дорогущий загородный дом. За 100 лямов например. И решили сэкономить на архитекторе, и попросили нарисовать архитектуру ИИ. Предположим, у вас есть доступ к наикрутейшему строительному ИИ. И он, по вашему запросу нарисовал вам шикарный дом. Вы его построили, вложились, всё обустроили, въехали туда, и решили жить долго и счастливо. Вы там прижились, дом и вправду получился шикарный, удобный, тёплый и уютный. Но, через 3 года вы заметили трещину на стене возле входа в подвал. Трещина небольшая, и на вид нестрашная. Вы замазали её раствором, покрасили, и на этом успокоились. Но, через пол года трещина появилась вновь, начала расползаться, проникла в комнату. И как бы вы её не замазывали, она появлялась вновь, и становилась всё длиннее и шире. В доме появилась сырость. На стенах начала расти плесень. Посыпалась штукатурка с потолка.

Вы вызвали специалиста. Он обследовал дом, и говорит, что при проектировании была допущена одна ошибка - ИИ не учёл характер грунта под домом. Там подземные воды и плавуны. И заложил недостаточно прочный фундамент для такого грунта. И, под действием веса дома фундамент начал разъезжаться. И что замазывание трещин вам ничем не поможет - через год максимум дом неизбежно развалится.

Что мы на этом примере видим. Первое - гигантская стоимость архитектурной ошибки. Второе - стратегический уровень риска. Если вам криво поклеили обои - их не проблема переклеить, и с домом ничего не будет. А если вам заложили недостаточно прочный фундамент, то дом развалится целиком, и вы потеряете всё.

Почему такое произошло? Да потому, что проектирование архитектуры это прежде всего умение просчитать ситуацию на 100 шагов вперёд. Оценить и минимизировать риски. Избежать оверинженеринга. Для этого недостаточно просто прочитать книжку по шаблонам проектирования. Нужен богатый жизненный и профессиональный опыт. Нужна адекватность и ответственность. Нужен элементарный здравый смысл. Т.е. тут нужны качества, которых у ИИ нет и не предвидется.

PS

На всякий случай - в строительстве домов я разбираюсь примерно как свинья в апельсинах. Поэтому мой пример это не более, чем художественная аллегория. Не надо в ней искать "инженерные" ошибки.

Был классный пример из книги совершенный код, где студент нашел неоптимальный цикл в проекте, ускорил его в порядки, и пошел хвастаться, а ему сказали, что это был цикл "бездействия системы"

Цикл бездействия системы имеет смысл только тогда, когда внутри цикла поток уходит в спячку и освобождает ресурсы. А иначе busy loop получается, который просто на 100% загружает одно ядро ненужными действиями.

Если было что ускорять, значит внутри цикла поток в спячку не уходил. И значит тут оба неправы - и студент, который "ускорил" этот цикл и автор цикла, который бездействие системы реализовал с помощью busy loop.

Когда совершенный код писали, другие реали были.

Тогда какой смысл опираться на практики из "других реалий" в современном мире? И приводить эту книгу в качестве примера?

Очевидно, что смысл примера в том, чтобы показать, что оптимизация нужна далеко не всегда.

Только вот новичёк этот ваш пример из "другой реальности" воспримет буквально, и пойдёт busy loop писать. Не лучше ли приводить более актуальные примеры для объяснения азбучных истин?

Но и фигню довольно часто предлагает. На одном этом даже ощущения "переломности/не переломности" не построить.

Но мне и малого достаточно, что теперь я свободно ориентируюсь там, где раньше неделями пришлось бы изучать детали.

LLM никогда не откажется что-то предложить, это да. В этих ваших скулях не знаю, может там что и по другому, а вот в моих применениях процент пользы в этих его предложениях настолько мал, а проверять это настолько тяжело, что польза сугубо отрицательная

А вот совсем уже и не факт. Как раз тот же Клод может предлагать ничего не делать и варианты "и так сойдет"

А мне эти же ИИ выдают код с переполением int, утечками памяти или неоптимизированным использованием пзу вместо кэширования

Это просто та же самая ситуация, что и с дельфинами («Те утопающие, кого дельфины толкали к берегу, рассказывают, что дельфины спасают людей. Те утопающие, кого дельфины толкали от берега, уже никому ничего не расскажут»). ГСЧ выдаёт правильный ответ — «уууууу, смотрите, какое оно умное!», ГСЧ выдаёт неправильный ответ — «это фигня, надо просто попробовать ещё раз (а потом ещё и ещё)».

"Ошибка выжившего"

НЛО прилетело и опубликовало эту надпись здесь

Или просто используете глупые ИИ, или не умеете пользоваться. Вариантов много

Как насчёт такого финта ухами: я даю Вам, вооружённому любым ИИ по Вашему выбору, которым Вы «умеете пользоваться», тестовую, но абсолютно реальную задачку (которую я, ничтожный человечишко, вполне себе решил) — и мы вместе посмотрим, в реальном времени, как оно шмогёт за пять минут?

(Прикол в том, что этой задачки нет ни в каких задачниках, но она имеет абсолютно формализованный критерий успешности решения: код либо работает, либо нет, и по заданным входным данным либо выдаёт известный правильный ответ, либо нет.)

Статья как раз про тестирование AI на задачах которых нет в задачниках. Вы же не думаете что его тестят только на задачах с опубликованными решениями?

Ой, а можно мне, только не в реальном времени?)

Интересно взглянуть на такую задачку.

В двух словах и очень упрощённно: имеется исходный код на языке L1 (LLMки этот язык знают, проверял) некоей софтины S1. Известно, что софтине S1 был дан файл F1, и в результате её работы получился файл F2. Задача: на другом языке написать софтину S2, которая, если ей дать файл F2, вернёт файл F1. Использование библиотек разрешено.

Там потери данных при прямом преобразовании не происходит?

Я же говорю: программу, выполняющую обратное преобразование, я лично написал, и она работает (по файлу F2 возвращает файл F1). Следовательно, решение существует, и LLM должно шмочь. Если, конечно, оно хоть наполовину такое же умное.

Код софтины S1 короткий, всего около 2-3 кб, работает в реальном времени. Код софтины S2 ничем не ограничивается.

(А потом есть следующая задача, со звёздочкой — тот же принцип, но преобразование уже с коррекцией ошибок; файл F2 пусть и может содержать ошибки, но файл F1 всё равно получается правильный. Код тоже мной написан и работает.)

Так если f1 постоянен, то просто вернуть f2 целой заготовкой и номинально это будет подходящим решением для ТЗ. Но будь все так, Вы б этого не писали, верно?

Поэтому сразу вопрос - не происходит ли потери информации при прямом преобразовании f2 = s1(f1) , содержит ли f2 всю полноту информации для обратного преобразования?

Так то даже задача f2=s2(f1) так, что бы f2s1=f2s2 не самая тривиальная, если язык (и типы данных и их обработка) s1 <> s2

Так если f1 постоянен, то просто вернуть f2 целой заготовкой и номинально это будет подходящим решением для ТЗ.

Да ради Сагана, пускай ИИ так напишет — и очень удивится, когда на «выпускном экзамене» на вход будет подан совершенно другой файл.

Немножко приоткрою завесу: речь идёт об одной (примитивной) СХД. А система, которая не может прочитать данные, которые сама же записала — мягко говоря, никому не нужна.

А чем продиктовано условие написать распаковщик именно за 5 минут?

Так-то задача не выглядит сложной, можно дать какой-нибудь модели через claude-code вместе с тестом где изначальная софтина будет сжимать, а новонаписанная расжимать и чтоб он фигачил пока тест не покажет, что файлы вначале и в конце одинаковые. Оно справится, если накосячит где, то ошибки искать умеет, но сделает не за 5 минут, а дольше.

с тестом где изначальная софтина будет сжимать, а новонаписанная расжимать и чтоб он фигачил пока тест не покажет, что файлы вначале и в конце одинаковые.

..И после N итераций окажется, что человек написал бы быстрее.

А чем продиктовано условие написать распаковщик именно за 5 минут?

Да можно не за 5, можно хоть за 65. Но оно должно всё сделать само, без подсказок человека (потому что мы сравниваем «человека против ИИ», а не «умного человека с ЕИ против ту не очень умного человека с ИИ».)

Но оно должно всё сделать само, без подсказок человека

Мне кажется все агентские тулзы для кодинга таким образом сделаны (как минимум, roo-code, claude-code, и их аналоги, не знаю про курсор). Оно само составляет план выполнения запроса, исполняет, тестит, исправляет ошибки и так до тех пор, пока не заработает.

Иногда, когда запрос слишком расплывчатый, предложит на выбор несколько вариантов выполнения на этапе планирования, и ты выбираешь.

Так я и говорю: дан исходный код функции, которая сгенерировала файл — куда уж однозначнее?

this contest, by using a scheduling problem as a subject, we will challenge a problem of finding a better solution instead of the optimal solution

Это же поиск эвристик. DreamCoder

ALE-Agent же придумал эвристику "виртуальной мощности", которая оценивает еще не запущенные машины так, будто они уже работают.

Да какие угодно эвристические функции, хоть в миллион шагов

Кроме того, агент реализовал нестандартные операции поиска в окрестности, позволяющие радикально перестраивать план и выходить из локальных оптимумов

Ого, просто удивительно. Глобальная оптимизация\Монте-карло?

***

Вообще парни из Sakana странные - написал им, что они там пробуют патентовать мой алгоритм, пусть вышлют денег - тишина :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Другие новости