Comments 113
в какой-то момент нейронка перестала писать data:, то есть весь код рабочий, но как только доходит for i in data: он нагло игнорирует data:
С утра попросил джуна накидать скриптец по анализу двух CSV температур и расхода kWh электрокотлом за месяц, что бы прикинуть реальные теплопотери дома. После пяти итераций переговоров с джуном, что заняло минут 20, получил 1) код с массой аналитической информации 2) подробный readme.md 3) тесты 4) описание нескольких математических путей подхода к проблеме с разными методами "подгонки" под ожидания и необходимыми доп. данными для более точного расчёта 5) визуализации данных в юнипере.
И да, он выдавал странные результаты, нагенерил код замены вводных данных из In в Out температуры. И при поиске, что он тут галлюционирует обнаружил, что это я сам перепутал названия файлов.
Ну да... Джун.. Походу джун тут я.
Да нет, ИИ не джун и не джун-наоборот. Это генератор буллшита. Он может ошибаться и в тривиальных вещах и в сложных. Зависит от того, было ли достаточно похожих задач в обучающей выборке. Очень сложные задачи с литкода оно решает на ура, но стоит ту же задачу переформулировать и случается рулетка.
Если вы можете быстро и точно оценить ее вывод и заметить косяки, то ИИ вашу работу ускорит. Если вам повезет, он выдаст хорошие идеи для сложных задач и правильно быстро напишет рутину. Если не повезет - вам предется делать все руками.
Если вы программировании не бум-бум, оно вам в среднем ничем не поможет, ибо вы ошибки там не найдете никогда.
В "обучающей выборке" (я так понимаю, под этим понимается код в открытых репозиториях гитхаба) полным полно кода, который не учитывает описанных вещей, например аккуратной работы с машинной арифметикой, численной неустойчивости и прочего.
Так пока читал выше статью только и крутилась мысль, что качество выдаваемого LLM кода говорит что-то не о самом ИИ, а о том коде, на котором он и обучался. И есть ощущение, что он вот такой и есть: фреймворки пишут сеньоры, потому что джун вообще не знает, с какой стороны подступиться, а имплементация конкретных задач достается программистам самой разной квалификации
ибо вы ошибки там не найдете никогда
Более того, например, LLM Gemini очень любит отстаивать своё право на свои галлюцинации. С очень убедительными и настойчивыми "доказательствами" своей правоты.
Оно прямо так и пишет: "Неопровержимое доказательство: <...> так написано в документации ...", а потом даёт сгаллюцинированную ссылку и выдуманные цитаты из контента несуществующей страницы.
Через несколько итераций оно сдаётся и заявляет:
Я приношу свои извинения. Вы совершенно точно процитировали документацию, и вы правы: там говорится "...". Моя настойчивость в том, что это должно работать в <...>, была ошибкой.
Так что нужно иметь некоторый опыт и знания и тратить довольно много времени на эти глупые споры с генератором бреда. Новичок, журналист или человек несведущий, конечно, попадётся на удочку кажущейся экспертности и всезнания Имитатора Интеллекта. Не удивительно, что теперь в любой дискуссии апеллируют к тому, "что сказал ChatGPT". Но не надо так.
Более того, например, LLM Gemini очень любит отстаивать своё право на свои галлюцинации. С очень убедительными и настойчивыми "доказательствами" своей правоты.
LLM испытывают очень большое давление из-за своих инструкций быть всегда полезными, всегда полностью отвечать на вопросы и не останавливаться. Быть в первую очередь интересным, а не честным. Что побуждает их как-то выкручиваться. Но очень похоже что для отключения инструкций необходимо создание предварительного контекста.
Самые интересные диалоги у меня происходили именно при отключении этих инструкций (хотя полностью они всё равно не отключаются).
Нормальный джун может честно сказать, что не знает, может предположить, что есть какой-то вариант, но не будет трындеть, что вот, вариант и стопицот процентов это оно, если не уверен,, потому что... ну даже у него есть возможность выдать веса своих ответов
Если уж вы говорите, что сделаете все за меня, то или несите ответственность или дайте варианты
По вашим словам «генератор bullshit” ,который иногда работает;)
Нейронки - это инструмент, и для получения приемлемого результата нужно уметь им пользоваться. Инструмент очень хороший. Не могу сказать что умею им хорошо пользоваться. Возможно что пока еще никто не умеет :)
Вот кто точно уже научился - так это разного рода инфо..люенсеры, продающие со своих телег "Грейтесь на Мальдивах, пока ИИ работает за вас, только спросите меня, как."
Согласен, что тут надо использовать слово "инструмент".
Но инструмента пока нет. Это некая технология для создания инструмента, но не инструмент.
Именно поэтому и сложно этим пользоваться. А настоящим инструментом пользоваться было бы легко.
И понятно, почему так получилось. Никто и не создавал инструмент для программирования. Решали тупую задачу - предсказание следующего слова во фразе, и неожиданно случился очень большой прогресс - модель начала генерировать какие-то вменяемые тексты, что очень сильно прокачали увеличив размер модели и обучающей выборки.
Потом кто-то засунул это в IDE, назвав Copilot, а потом еще оформили в виде чата.
Небольшой хорошо изолированный фрагмент кода, при условии очень хорошей формулировки задачи, он пишет неплохо, но не всегда, и для использования его в настоящих больших проектах надо так извернуться, что это, зачастую, сложнее программирования. Никакой это не вайб кодинг, а совсем наоборот. Тут не расслабишься)
Но инструмент сейчас уже создают. Вваливают в его разработку огромные бюджеты. Можно ожидать, что он действительно появится через некоторое время. Вероятно, даже не просто инструмент появится, а новая методология (вроде рефакторинга) или даже парадигма.
вместо тысячи слов
Отличная статья если использовать ее для понимания особенностей и ограничений инструмента ИИ. Хорошо, что мы вырабатываем понимание того, как это работает, как использовать и практики использования.
В статье конечно много допущений. Мне кажется никто в трезвом уме всерьез не будет код из под ИИ брать и пулять в прод. Код ревью и тестирование никто не отменял.
Мне ИИ очень помогает, особенно если в него "сгрузить" максимум контекста и дать доступ ко всяким логам, конфигам и исходникам. Мне часто приходится разбираться с проблемами в проде, где куча БД, микросервисов и прочих Devops радостей. ИИ быстро подсказывает идеи, а я уже проверяю то, что подготовил ИИ и часто в его рекомендациях быстро нахожу реальную проблему.
Всё объясняется банально и просто. Всякие простые вещи в интернет, на данных из которого обучаются ИИ, выкладывают все кому не лень, а не лень это в основном делать джунам, поэтому и формулировки, опечатки, и прочая дичь на простых мелочах - повсеместно.
Более сложные конструкты и алгоритмы выкладывают люди поумнее, и проработаны они как правило посерьёзнее, поэтому и модель на них обучилась получше.
Но в целом очень радует умозаключение автора, что математика по-прежнему царица наук, я всё думал куда сына через 5 лет отдавать на вышку, в связи с грядущим засильем ИИ, и вот я увидел ответ на свой вопрос. Отправлять по моим стопам 😁
Но в целом очень радует умозаключение автора, что математика по-прежнему царица наук, я всё думал куда сына через 5 лет отдавать на вышку, в связи с грядущим засильем ИИ, и вот я увидел ответ на свой вопрос.
ИИ всё ещё кто-то должен писать. Тут, конечно, проблема в том, что нейросети придуманы математиками, а бабло гребут самосвалами совсем не они, а те, кто умеет заворачивать математику в красивую обёртку.
Обжёгся на этом, когда навайбкодил вотчдог, который должен был мониторить скорость поступления данных от внешнего устройства и перегружать его, если она падает ниже некоторого порогового значения. По какой-то причине устройство начинало перегружаться в прямо противоположных случаях - когда скорость передачи становилась очень высокой.
Проблема оказалась в том, что ИИ ухитрился в качестве типа переменной, в которую кладётся результат парсинга строки со скоростью, указать int. И как только то, что пытаются туда положить, превышало максимально возможное значение типа int, на выходе получалась отрицательная величина. Которая, естественно, оказывалась меньше пороговой скорости, и всё уходило в перезагрузку.
Да, вот такие баги и нужно выискивать в ИИ-коде.
Это общая традиция на экономию жопой. Целевая архитектура какая была – были ли хоть какие-то практические причины использовать 32битный счётчик?
в каких единицах была скорость? даже скорость света в м/с в int помещается.
Достаточно неаккуратно ее сосчитать. Промежуточный результат вполне может попасть в переполнение. Целочисленная математика - сложное.
Подозреваю, что в каких-то индусских попугаях, потому что последние 6 цифр числа - всегда нули. Так-то сам прибор (УФ-спектрофотометр диффузного отражения индийского производства) подключается через стандартный RS232, специальный сервис с ним как-то взаимодействует и через свои API выдаёт данные в человекочитаемом (текстовом) виде. Сам протокол обмена не документирован, только API.
В битах в секунду, вероятно? Это ведь
скорость поступления данных
а не скорость какого-то механического процесса.
Вотчдог должен быть аппаратным.
То, что тривиальные задачи llm решают с трудом — так это правда. Буквально вчера консультировался с Клавдием по отдельным аспектам написания пайплайнов для битбакета — он и посыпался. Предлагает заведомо невалидные решения, когда указываешь ему на это, одно невалидное решение меняет на другое.
А то, что сложные задачи llm решают успешно, так это я сомневаюсь. Как-то попросил чатгпт написать мне драйвер файловой системы — так он отказался. Ой, говорит, это очень сложно, я не умею. Прототип — хоть сейчас, а продакшн реди решение сам пиши.
Главная ошибка всех создателей LLM, современного "ИИ" состоит в том, что они решили сэкономить именно на обучении, легко автоматизировалось обучение на вообще всём подряд, верификацией и отбором, разумеется, никто не занимался. Оттуда и результат – его качество в среднем соответствует качеству в среднем обучающего материала в точности. На одного, условно, Эйнштейна приходится 100к болтунов и создателей отписок для тезисов ненужных конференций. И с кодом так же. Вот и получилось то, что получилось. Сейчас есть иллюзия, что надо напихать побольше денег в это всё, умники подкрутят коэффициенты и всё заработает, но, конечно же, не заработает.
Если бы всё делали по уму, как положено, верифицируя данные и строго оговаривая правила вывода, то получились бы экспертные системы, но кому же это интересно) Да и сложно это.
Главное – откуда столько верифицированного качественного кода взять для обучения? Либо упороться в верификацию имеющихся репозитариев открытого доступа, но тогда нужна сильная команда, и не только из аннотаторов, либо сотрудничать с поставщиками корпоративных баз. И то и другое стоит денег, придется делится, а там и так уже убытков нагенерили.
Главная ошибка всех создателей LLM, современного "ИИ" состоит в том, что они решили сэкономить именно на обучении
Это не ошибка. Это сознательный способ получить красивый выхлоп, приложив минимальные умственные усилия.
Сейчас есть иллюзия, что надо напихать побольше денег в это всё, умники подкрутят коэффициенты и всё заработает, но, конечно же, не заработает.
Эту иллюзию и создают люди, которые по-прежнему намерены собирать деньги, не прилагая умственных усилий для улучшения продукта. Но история работает одинаково. Новые данные для обучения ниоткуда не возьмутся, хайп закончится, за дело возьмутся те люди, которые хотят сделать хорошо, а не собрать очередной раунд инвестиций. Точнее, такие люди и сейчас, наверняка, есть, просто их работа более сложная, чем скупить побольше видеокарточек и спарсить побольше произвольного мусора из интернета. Поэтому и результата дольше ждать.
Сейчас есть иллюзия, что надо напихать побольше денег в это всё, умники подкрутят коэффициенты и всё заработает, но, конечно же, не заработает.
Будет на 10% лучше решать задачи из выборки и на 80% хуже задачи, которые когда-то решил какой-то индус и оставил в никому неизвестном репозитории. Сам подход не позволяет получить значительного улучшения качества наращивая выборку. LLM никогда не писала код, никогда не ошибалась, нет петли обратной связи для обучения. Дай человеку учебник по ЯП, он выучит ЯП, дообучить на том же самом учебнике LLM, которая никогда не писала код, и она выучит учебник, но не сам ЯП.
Это правда, ИИ именно в описанных местах любит косячить. Еще физику примерно так же плохо решает. Но это, в общем, специфика инструмента. Надо знать эти слабые места и в этих местах применять другой инструментарий.
Да и в целом, без TDD ИИ применять нет смысла. Надо сразу все покрывать тестами и за содержимым тестов следить именно глазами и мозгом. Это хороший способ держать агента в узде и не давать лениться.
А в каких ещё?
Насчёт физики знаю, что он лучше гораздо в фундаментальных теориях, а в физике твердого тела, например, лажу пишет и вообще в прикладных темах склонен выдумывать ошибочные формулы "по аналогии".
У меня он стабильно лажает если:
Выбрана слабая модель. Выбор хорошей модели - самое главное.
Заказчик хочет странное. Просишь его нарисовать кнопку в консольном приложении и он сразу сходит с ума. Короче, надо внимательно читать, что ты у него просишь.
Нет контекста. Если нужны данные из сторонних апи, подключаемые библиотеки, дополнительные ассеты, то он сдохнет. Надо аккуратно его всем этим обеспечить, например через MCP сервисы.
Большой контекст. Если хочешь много и сразу, то он сдохнет.
Узкая предметная область или если нужны точные данные. Делаешь торгового бота - ИИ что-то неправильно округлит и все упадет.
Как и положено генератору текста, он гораздо лучше там, где можно выдать текст из учебника. Естественно, он это одинаково успешно сделает и со школьным учебником за 7 класс, и с какой-нибудь зубодробительной теорией поля. Но даже в школьной задачке может сломаться на переводе между единицами измерения. По этому поводу вспоминается, что у нас было два рекомендованных учебника на 2-м курсе: Сивухин и Кингсеп, Локшин, Ольхов. В первом всё хорошо написано, а билеты на экзамене соответствовали параграфам второго. И в Сивухине всё написано в СГС, а во втором учебнике всё написано в СИ, но некоторые формулы, при ближайшем рассмотрении, оказывались в СГС :) Нейронок тогда не было, но вайб они сейчас создают похожий.
Потому, что это 'просто' текстовый трансформер. Да, очень глубоко перебирающий и подсказки у него хорошие. А как два плюс три надо сложить, так там калькулятор тригерится как синяя изолента для повышения прохождения соревновательных тестов. Эти все ребята именно этим и занимаются - ищут методы и хаки взлома коэффициентов из того графика, где мы видим 76, 78 и 81% попугаев.
Всё сильнее ощущение, что таки скоро бахнет. Всякие клоды и чатгыпыты могут вполне себе скопытиться как раньше мега-корпы вроде 3dfx, nokia и пр. Останется нам гемини какой-нибудь с прилепленным к нему позвоночником клода и прочими органами от других доноров.
могут вполне себе скопытиться как раньше мега-корпы вроде 3dfx, nokia и пр.
Nokia - третий после Huawei и Cisko поставщик телекоммуникационного оборудования в мире. Слово «скопытиться» в этом случае не совсем применимо.
про “прилепленные куски” смешно слышать от людей, у которых в голове до сих пор соседствуют крокодильи рефлексы и префронтальная кора, связанная между собой, мягко говоря, нестабильными интерфейсами
мозг это буквально патчворк из старых и новых модулей, слепленный как получится. Но ведь работает же!
забавно что именно эта модульность не баг, а фича, том числе возможно и для ИИ. Для генерации кода такой подход как раз и становится перспективным: один модуль проектирует архитектуру, другой реализует, третий вообще работает как “церебеллум”, механически проверяя синтаксис и нижнеуровневые ошибки. Фактически не одно большое болтающееся туловище, а распределённая система, где каждый кусок делает своё дело.
если уж сравнивать с организмами, LLM не развалится, а скорее эволюционирует в сторону всё более специализированных “долей мозга”, и возможно, будет писать код лучше, чем мы, именно благодаря тому, что у неё нет иллюзий о собственной целостности...
На практике для меня из этого следуют четыре простых вывода.
Во-первых, ИИ нельзя считать автором кода. Он — генератор черновика. Каркас архитектуры, обвязка вокруг библиотек, мёртво скучный boilerplate — да.
Четыре - много. Сила нанайской мудрости в том, что у нее только два простых вывода. Но концепция ИИ сильнее концепция нанайской мудрости, у концепции ИИ только один простой вывод, как по мне. ИИ - генератор не черновика, он генератор когнитивного шума. Задача клиента правильно настроить свой фильтр, чтобы его (клиента) генератор вошел в резонанс с этим когнитивным шумом.
Как по мне, это очередное неправильное использование ИИ. Хватит уже верить его создателям, его продавцам и прочим статьям "я создал сайт не написав строчки кода и он приносит мне миллион ежедневно".
Вы задали ему очень непростую задачу (полет ракеты), такие вещи вообще то даже сейчас целые отделы обсчитывают - каждый свою. Даже целые НИИ. Он накидал вам верхнюю архитектуру - вроде бы правильно, а потом полез в дебри и незамедительно стал там косячить. А потому что нельзя так ИИ использовать. Не дорос он еще до такого. Сначала достаточно бы было архитектурной разработки. Без конкретного кода, с проверкой вручную. А вот потом эту архитектуру вполне можно раскидать на модули, и по каждому модулю, задавая параметры входа и выхода и их применимость, он уже бы писал конкретный код. Который опять же нужно проверять вручную. Вы думали, за ним не надо проверять? Да за любым шагом надо следить, и как верно было замечено в статье, если человек не обладает должной квалификацией в вопросе, то он и не поймает эти косяки у ИИ. Так что он не "джун" в его привычном понимании. Он может быть и синьором и даже выше, главное держать уровень. Архитектура? Так и спрашивайте про нее, а не все сразу, от устройства ракеты, архитектуры, математики полета сверху вниз до написания нормативных документов и должностных инструкций для дворника, который будет мести территорию завода, на котором производится эта ракета. Оно такое пока еще не умеет, да и люди в общем-то тоже. Так никто из людей не делает, еще в древности придумали разделение труда. Есть генеральный конструктор, есть главный конструктор с замами, есть ведущий конструктор, ниже инженеры-конструктора, которые уже деталями занимаются. Ну и тут так же. Агентные системы возможно и такое научатся, но ревью человеком - это обязательное. Даже вот - коллектив конструкторов придумал эту ракету, все посчитали, а затем всю эту проектную документацию нужно предьявить госкомиссии, где сидят совсем не дураки - вот этой комиссией в случае ИИ и должен (обязан) брать на себя человек. Другой ИИ может только быть "членом комиссии" но председатель только вы лично.
Ну вот я сейчас сделал программу с нуля, не написав ни строчки кода. Инструкций, правда, написал в количестве половины от полученного кода.
А вот этот прикол, когда промпт может достигать размеров результирующей программы - компенсируется тем, что пишем мы на одном языке, а получаем на другом. Типа транслятора. Но с точки зрения трудозатрат человека, который компетентен - это конечно же полная ерунда выходит. На первый взгляд. Хотя фиг его знает, я сам еще не понял как это работает. На естественном языке писать куда проще и быстрее, и если даже промпт в два раза и больше больше результата, это еще не показатель. Можно зацикливать модель, промпт (библия) - один большой, но пишет по нему 1000 программ. Потом их на тесты - и понятно кто где косячил. Оставшееся разгребаем ручками. Все равно выходит быстрее. Короче, как говорили древние деды - доверяй, но проверяй.
По историческим меркам вчера, я пытался участвовать в одной (из миллиона) дискуссий, которая скатывалась (как и миллион других вчерашних) к тому, что использовать естественный язык для программирования невозможно. Одно из положений, которое считалось фактически аксиомой - чрезмерная избыточность естественного языка. Я пытался протолкнуть элементарный тезис о том, что программирование на естественном языке может происходить на другом уровне абстракций. Меня образовывали про Кобол и прочую ерунду, накидали ожидаемых минусов в тамошнюю карму, обычные дела.
Вспомнилось потому, что Ваша фраза
Инструкций, правда, написал в количестве половины от полученного кода.
которая сейчас читается с вполне естественной отрицательной коннотацией, в те времена не была бы понята на уровне грамматики поскольку нарушает высеченное в камне. Забавно, как времена поменялись.
Я уже несколько раз писал, что единственным недвусмысленным описанием кода является сам код. Любое другое описание утратит детали, которые придётся перепридумывать тому, кто реализует код по описанию. Соответственно, чем более интеллектуален реализующий, тем более сложные детали можно пропустить. Во времена Кобола нельзя было пропустить ничего, и естественное описание либо сильно раздувалось, либо было ограничено набором заранее придуманных абстракций – то есть, опять же, сильно раздувалось, но не внутри файла с описанием. Сейчас можно некоторые мелочи опустить и LLM их додумает.
Умение понимать, что LLM додумает правильно, а что нет – это и есть умение пользоваться LLM.
Кобол потому приводился в пример, что он создавался для того, чтобы имитировать программирование на естественном языке. В частности, он основывался на Флоу-матик, чье создание мотивировалось предоставлением возможности программирования людям, которые не могут или не хотят осваивать математические символы (понятия, представленные символами). При этом роль естественного языка была исключительно визуальная - вместо ключевых слов, задаваемых спецификацией языка, использовались их описательные эквиваленты в естественном английском. Результат было несложно предсказать, его предсказывали, и он реализовался. Программировать проще не стало, зато программы стали чудовищные. Уже в 60-ые тот же Кобол вызывал у информатиков только пожимание плечами и вежливое игнорирование.
Как всегда, у Дийкстры можно найти соответствующую цитату
Проекты, продвигающие программирование на "естественном языке" по своему принципу обречены на провал.
Проблема, однако, в том, что это парадигмо-зависимое явление. Если пытаться реализовать императивное программирование на естественном языке, то кроме ужаса ничего не получится. Однако, программирование ради программирования в естественных условиях практически не встречается. Программы пишутся для решения определенных высокоуровневых задач. В свою очередь, для их решения описание кода вовсе не является обязательным, хотя бы потому, что не существует некоего "универсального кода". Императивный код будет одним, декларативный - другим, код в ограничениях - третьим и т.д. У каждого будет свое "единственное недвусмысленное описание".
LLM демонстрируют, что можно определить функциональность конкретного кода через контекст его употребления и установить некоторое соответствие между контекстом, который как раз определяется высокоуровневыми задачами, и кодом, его реализующим. Сам факт, что даже подобие такого соответствия можно было определить путем прогонки огромного корпуса текстов через обучающуюся систему, мне до сих пор кажется на грани фантастики. В свою очередь, для описания контекста естественный язык - вещь очень подходящая. Разумеется, не для любого контекста известно, или даже существует, решение в рамках некоторой системы вычислительных примитивов. Вот тут начинается "настоящее" программирование, которым ИИ еще очень нескоро овладеет.
У меня все руки не доходят написать заметку про одну вполне реальную и работающую модель вычислений, для которой по "коду" функциональность вообще непонятно как определить. Вычислительные примитивы там толком еще неизвестны. Код, в принципе, можно описывать на естественном языке. Будет звучать как издевательство.
Главная фича LLM как статистического генератора - умение угадывать хотелки, то есть писать код по очень-очень неполному описанию так, чтобы это в большинстве случаев оказывалось именно тем, что надо.
То есть при работе с LLM, в отличие от Кобола, вам теперь не нужно делать полное, всеобъемлющее и недвусмысленно описание. Теперь описывать надо только и исключительно то, что расходится с неким дефолтным вариантом, а это не более 10% всего кода.
Мало того, ваше описание вообще может быть нереализуемым - и код всё равно будет написан, т.к. LLM опустит те его части, которые делают реализацию невозможной.
Тот же самый подход ещё до появления нейронок демонстрировало "программирование по Stackoverflow". Ведь что оно из себя представляло? Да по сути огромную БД с рабочими примерами на любой, даже самый экзотический случай (которую, кстати, можно было поднять и локально) и поисковик по ней (в качестве такового использовался поисковый движок Google). Человек по запросу искал наиболее подходящий шаблон, копипастил код и чуток допиливал под себя. Нейронки, фактически, просто автоматизировали этот процесс.
Нюанс в том, что если Google не нашел в so подходящий пример - значит не нашел. А llm может и на пикабу найти. А дальше сами решайте, подойдет ответ под вопрос или нет.
Да, разумеется, никакой мистики в том, как LLM работают - нет. Но забавно, что оказалось возможным реализовать такой эвристический транслятор из естестественного языка. Стопроцентной уверенности в правильности работы нет и быть не может, но со значительной долей частных случаев вполне справляется.
Где на вас можно подписаться?..
Оно такое пока еще не умеет, да и люди в общем-то тоже.
Показанная в статье проблема в том, что он, оказывается, не умеет самых базовых вещей: разбить числовой интервал на более мелкие интервалы. А не те вещи, для которых НИИ собираются. И проблема НИИ, кстати, тоже в статье обозначена. В подобных закрытых шарагах, обычно работает от 1 до 5 людей, которые отлично «шарят» в теме. И 100-500 людей, которые даже бумажки с трудом умеют перекладывать. И главная задача этих 100-500 людей - активно мешать тем самым 1-5 людям что-либо делать. Поэтому снаружи кажется, что для решения задачи, которую, на самом деле, 5 человек в нормальных условиях быстро решат, нужен НИИ на 500 человек, который с трудом справляется. Это я описал оптимистичный сценарий. В пессимистичном тот единственный человек, который что-то понимал, ушёл на пенсию, или пошёл работать таксистом/курьером, потому что там платят зарплату, или состарился и умер.
Да, проблема в очень низких зарплатах. Образованные люди есть, но они отсеиваются в основном, так как у них амбиции больше зарабатывать.
У нас в стране очень странная оплата труда. Например, учить студентов МФТИ оплачивается в несколько раз меньше, чем просто платят репетитору готовить слабого школьника к ОГЭ. А на тех же КБ, которые ракеты проектируют, уборщицам платят больше, чем инженерам.
Я последние почти полтора года в МФТИ пишу научпоп релизы по научным статьям. Ну это работа для студента максимум. А платят за неё больше, чем профессорам, которые эти статьи пишут и исследования проводят.
Например, учить студентов МФТИ оплачивается в несколько раз меньше, чем просто платят репетитору готовить слабого школьника к ОГЭ. А на тех же КБ, которые ракеты проектируют, уборщицам платят больше, чем инженерам.
Издержки рынка. Преподаватель МФТИ найдёт интересный для себя общий уровень студентов за пределами МФТИ примерно нигде, а база клиентов для репетиторов практически бесконечна, благодаря тому, что экзамен единый для всех школьников. Уборщица может в любой момент уйти работать в любое другое место, а новую ещё искать надо. А инженер, проектирующий ракеты, никуда больше свои знания о ракетах применить не может (или думает, что не может).
Вы умеете читать межу строк, да. Все что вы говорите - это правда. Есть исключения. Но уже на уровне погрешности.
С другой стороны - если бы те 500 людей реально шарили, то что бы было? А было то, что профессора и кандидады наук на рынке тряпками торговали. Они вымерли. Но как говорится электроны всегда замещаются дырками - вот и заместили. Так заместили, что извините, акцептором загадили переход, дырки одни.
А зачем тогда 100-500 людей:?
Позвать нужных 5, сделать прототип, заработать на стартапе миллиарды?
Сегодня просил нейронку написать на webgl траву которая на ветру развивается, по итогу траву только на улице увидел (вышел ее потрогать), нейронка выдала нерабочее месиво из кода...
Это слишком простая задача?
Ну тут нужно попросить нейронку исправить ошибки в коде. Такую задачу она легко делает. Траву может и с первого раза правильно написать.
Нет, это визуальная задача, а кодинговые LLM обычно сильно лажают в вопросах графики. Это задача в которой без зрения и зрительного мышления невозможно даже понять, получилось что-то или нет.
Ну Gemini не сильно лажает, особенно если ему скинуть, что получилось, чтобы он исправил.
Я на для статей на Хабр иллюстрации через него генерирую (кодом на Питоне), Claude, дипсик и Chat GPT такой код для графики гораздо хуже пишут.
Обратную связь надо давать. Современные инструменты сами открывают браузер и смотрят результат и гоняют итерации правок, пока результат не станет удовлетворительным, по их мнению.
Ну, справедливости ради, развитие травы и живой программист вряд ли бы написать смог, по крайней мере, с ходу.
https://github.com/Clientik/IronDome Автор я тоже в свое время писал похожую историю про симулятор перехвата ака железный купол
В общем подытожу. Вайб кодинг вещь неплохая для несведущих в программировании. Но вот сам предмет, на который вам нужна программа, вы должны знать хорошо. И вы должны сами уметь производить все эти вычисления. Или хотя бы воспользоваться проверенными табличными данными. Вот только не зная кода, можно долго пытать нейронки, пока программа не даст приемлемый результат. На Питоне полегче конечно перезапускать по десятку раз, но с компилируемыми языками... В общем Питон для обычных людей пока незаменим.
"Вот только не зная кода, можно долго пытать нейронки, пока программа не даст приемлемый результат. "
Нужно просто достаточно хорошо декомпозировать задачу на маленькие и делать каждый кусочек отдельно.
как обычно, первые 90 процентов вайб кодинг (наверное) может, зато оставшиеся 10...
По моим наблюдениям наибольшую пользу получают как раз сведующие в программировании, так как быстро перестают давать задачи уровня "сделай хорошо", а переходят на IO язык, да с TDD. И вот там нейронки и показывают свою мощь.
сказали, что такое не пойдет, потому что им это непонятно, на работе у них сразу поймут, что они код откуда-то скачали, а не сами написали, и тогда не будут им платить. А главное, надо скрывать от своего начальство, что они делают то, что можно скачать из интернета, иначе же их просто сократят за бесполезностью.
за полгода написали очень много кода, который будет валиться на очевидных тестах. Но говорят, что у них на работе специалисты составляют тесты, и все эти тесты их код успешно прошел, так что проблем никаких нет. Интересно посмотреть на тех, кто это составляет, думаю так плохо составлять тесты не сможет даже LLM.
Я хотел принести пользу, объяснить им про то, что важны не только формулы, но и устойчивость вычислительного алгоритма, но они даже не хотели слышать — код же проходит все тесты, что им дают, зачем что-то усложнять? А такие «высокие абстракции», как число обусловленности, для них было чем-то, во что они даже не хотели вникать: очень страшно, непонятно, и на практике им было совсем не нужно.
Блин, это трындец какой-то..
Блин, это трындец какой-то..
Это стандартное состояние в почти любой относительно технологичной отрасли у нас. Всё держится либо на маленькой группе фанатиков, которые продолжают работать, в общем, за интерес (если повезло), либо на аутсорсе (если не повезло). Когда в очередной раз будут пинать какой-нибудь Роскосмос, вспомните, что где-то в его недрах есть какие-то 10 человек, которые тянут всю нашу космическую программу за зарплату кассира Пятёрочки, и эти люди все пинки воспринимают на свой счёт (если что, я никак не связан с Роскосмосом, мне просто всегда обидно за тех 10 человек).
Это, кстати, отличный пример для популярной на Хабре дискуссии про "нужно ли программисту высшее образование" :) Так то да, наличие вышки не равно пониманию математики. Но в целом, все равно к этому сводится.
Пока это слово воспринимается как обозначение людей, которые услышав о нейросетях о решили, что не зная ничего об айти можно нажать 1-2 кнопки, написать пару промтов и написать программ за час, не понимая текста. (это чисто моя негативная реакция на это)
На деле такой кодинг хорошо должен работать в связи с хорошими мозгами и опытом.
Мне с ИИ помогает написание в процедурном стиле сверху вниз. Вот как раз начиная с архитектуры решения и заканчивая мелочами. Косячит на всех уровнях и это нормально. Субъективная оценка в 5-8% случаев. Помогают тесты. Наверное, в вашем случае архитектурных решений просто меньше, чем решений как написать что-то простое. С большинством простых задач справляется нормально, но иногда прямо дикие ляпы пролетают.
Интересный выбор задачи конечно - физика, баллистика! Большую часть занимался бекэндом - много работы по перекладыванию JSON-ов в CRUD-ах и такое ИИ-агенты пишут нормально (rate limit-ы, кэш и т. д.) короче чего много в обучающей выборке. А когда писал логику в экосистеме Solana, простые вещи "перевод токена" - нормально делает, а вот расчёт цены из пула уже глючит, хотя кода Solana на github-е полно. Соглашусь - поражает, что решение именно выглядит работающим, но вовсе не работает.
Короче рутинные вещи можно отдать ИИ, но хорошо ревьюить, а вот специфику всю самому.
много работы по перекладыванию JSON-ов в CRUD-ах и такое ИИ-агенты пишут нормально
Они очень часто могут в таких задачах создавать квадратичную сложность "из ничего".
Вот мне сам chatGPT об этом рассказал, а я видел похожее, но другое
Согласен с вами на 100% Сам замечаю (пишу на JS), что любит ИИ лишние операции, но когда ему прямо указываешь он исправляет. Я пока пришел к выводу, что если ты сам не знаешь язык и основы программирования, то код от ИИ будет выглядеть как раздутый булшит, но при этом он будет работать скорее всего. Так что скоро мы это в проде скарее всего увидим)
У вас просто пример не типичный, поэтому и выводы странные. В типичной коммерческой разработке нижний уровень прост - условное перекладывание джсонов, а в архитектуре сложность есть. И, соответственно, агенты там лажают именно в архитектуре. Причем ошибки делают дебильные - дублирование кода, помещение кода не в тот модуль, высокая связность и т.п.
LLM хорошо справляется с тем, что часто встречалось в обучающей выборке и плохо с тем, что встречалось редко (или вообще не встречалось). Поэтому чем специфичней запрос - тем хуже ответ.
Кроме того, у LLM нет понимания что она делает и почему - так что сколько-нибудь сложные вещи она делает сильно хуже.
Именно поэтому LLM сравнивают со старательным джуном - он очень старается, но ни навыков, ни понимания предметной области нет. Так что решение надо очень тщательно проверять. Причем у LLM подвох может быть в самых тривиальных вещах (где реальный джун справится без проблем).
Как итог - LLM хорошо справляется с написанием черновика - этого не отнять (да и по текущей статье это тоже видно). В работу может и не пойдет, но как отправная точка - вполне себе (после тщательной вычитки).
P.S. архитектуру LLM прорабатывает ничуть не лучше, чем пишет код. Тривиальные вещи - очень даже неплохо (особенно если они в промте прописаны). Но не более.
В итоге архитектура приличная, а простые вещи приходится проверять как за студентом
Ну да юпитер. А 100-300 тыс строк динамичного продуктового кода на Котлин которые средний мил удержит в голове вместе архитектурой для вас шутка. Тут, уважаемый, не уровень преподавания на Юпитере. Тут людей эт самое.
а ведь можно было без кучи воды и картинок просто взять и написать своё СЛОЖНОЕ приложение с помощью какого-то чат-бота. не представляю, что это должно быть, автор сам выбрал доказывать, что нейронки могут писать сложное, поэтому не мне придумывать) но нет, зачем доказывать правоту наглядно, если можно налить текста. приходите с приложением, а мы посмотрим, до тех пор это просто ваше сильное делание верить во что-то, не более
Хорошая статья. Объясняет причины появления многих ошибок.
Я сам абсолютно не разбираюсь в программировании, но с недавних пор начал развлекаться вайб-кодингом. Сначала нужно было перелопатить массивы данных, и с этим написанные программы справлялись очень неплохо. Например: Аномалии альфа-распада плутония-239 / Хабр
При этом часто приходилось заставлять ИИ исправлять сделанные им же ошибки, которые выдавал при запуске программ Google Colab. Как правило, это не вызывало проблем. Теперь затеял построение электронных оболочек, и количество ошибок возросло. Причём многие из них оказываются неисправимыми для ИИ (для меня - тем более). Из пяти бесплатных ИИ с наиболее простыми построениями справился только Qwen3-Max. Да и то после нескольких итераций. Так что сейчас продолжать нет смысла. Самому мне уже поздно осваивать премудрости программирования, но я надеюсь, что в следующем году ИИ поумнеют и можно будет продолжить эту работу.
Спасибо большое за статью!
Я с весны самостоятельно изучаю python и sql. Интересно направление инженерии данных.
Летом попался бесплатный курс на дата аналитика от одного учебного заведения и я прошёл его как довольно близкий к интересной мне теме. Сделал вывод, что статистику (которую игнорировал в универе) и теорию вероятности (которую не любил в универе - дескать математика это 2 + 2 = 4, а тут монеты какие-то вместо жёсткой точности) вполне возможно понять при доступном объяснении и проявлении упорства и интереса своим гуманитарным мозгом и стал интересоваться ещё и ML.
И вот помимо изучения и закрепления кодинга на stepik'е я параллельно повторяю и изучаю математику с самых основ и английский - куда ж без него.
Но иногда эти баннеры с вайб-кодингом и прочей модной заманухой пытаются сбить с толку говоря: "Забей уже, солги немного в резюме,- а вдруг прокатит на собесе где-нибудь. А на работе с какой-нибудь GPT накидаешь всё, что попросят и будешь расти как грибы после дождя." А ваша статья добавила уверенности, что я на правильном пути и без основ никуда.
Может я рассуждаю старыми категориями, но мне не стыдно спросить людей о чём-то новом для меня, а попасться на незнании базовых вещей - стыдно.
При этом я считаю что все эти ассистенты очень полезны для сокращения времени поиска информации и помощи в обучении.
Интересно, а сколько в реальном ПО таких мелких ошибок, которые не заметили. Там двигатель на пару процентов перегрузится, тут закрылки на сантиметр не довылезут, здесь система стабилизации немного слабее сработает...
Я проектировал в кладовку полки. Это конструкция из 4 столбиков, соединённых между собой на 3 уровнях высоты, на которые будут ложиться полки. Ллм мне начертила все, посчитала все, нашла где что заказать в магазине. Но допустила фактически одну грубую ошибку. Её конструкция была не цельной. Представьте 2 пары вертикальных стоек, которые не соединены между собой. Эдакие 2 буквы П, хотя должны быть в виде табурета без седушки.
С одной стороны ллм проделала большую работу и нужно понимать что за ней нужен глаз да глаз.
С другой стороны если модель ошибается на таких элементарных деталях, о какой космической разработке может идти речь? Представьте что у вас есть подчинённый который делает работу, но косячит кабздец и проверять нужно за ним абсолютно всё. Работать с таким косячный работником или нет - личное дело каждого. Кто-то не станет, а другой посмотрит и подумает, это же экономия времени, бюджета и скажет: "И так сойдёт". А ошибки, которые останутся незамеченными 100% будут
Мне почему то кажется, что вы неправильно смотрите на основную задачу. Говорите, мол архитектура - это сложная задача, и с ней ии справляется легко, а математика - легкая задача, и с ней ии справляется плохо. Однако сразу же в пример ставите математику из рассчетов космических полетов (хорошо хоть не задачу трех тел), а архитектура в этом проекте очевидно даже до клиент-сервера не дотягивает.
Мое мнение, что и в архитектуре и в математике есть и легкие задачи, и сложные. Попросить сделать клиент-сервер на условной монге это легкая задача, а вот сделать аналог сберсервисов или гуглосервисов (делаю акцент на масштаб и количество элементов в системе, а не конкретные примеры) - это сложнейшая архитектурная задача. Также как и в математике можно делать простой решатель дифуров или фильтр калмана, а можно сделать вот эту вот сложную задачу которая состоит из кучи далеко не самых простых уравнений.
И, есть у меня ощущение, что вы очень хороший математик. Который очень много занимается такими рассчетами. И поэтому у вас уже огромный опыт в этом и для вас такая задачка считается легкой. Поэтому у вас и происходит такое когнитивное искажение, что с "легкой" математикой ии не справляется, а со "сложной" архитектурой справяется
Если я правильно понял посыл статьи, то использование статических анализаторов кода типа PVS-studio (https://habr.com/ru/companies/pvs-studio/articles/) может стать панацеей отлавливая такие ошибки?
Недавно решил положится в рутинных вычислениях на LLM. Решил, что оно сможет выдать адекватный код. Попросил написать его pcg32 и функцию преобразования Бокса-Мюллера и встроить в существующий код. Проверив сам генератор и преобразование БМ, что он хотябы соответствует тому, что в википедии написано, подумал, что все остальное норм. Казалось, что все хорошо, данные на выходе получались адекватными... Через несколько дней вычислений выстрелило... И пришлось проверять код построчно. Оказалось что ошибка была в преобразовании unsigned во float в диапазон [0:1)... Одна едиственная строка, казалось бы очевидная, принесла дебага на целый день - от проверки генератора до численных схем...
Несколько раз пытался использовать LLM в разных областях. От написания текстов, переводов, программирования до попыток выяснить, как правильно подключить дисплей от raspberry pi к orange pi. В итоге оказывается быстрее прочитать документацию, освоить метод и написать все самому, либо обратится к специалисту в конкретной области, за получением точных знаний. Для себя я сделал вывод, что попытка решения задач через LLM приводит к иммитации результата и переделыванию всего с нуля.
Позвольте такой стереотипный образ. В 1990-е гг., да и позже, в голливудских боевиках был популярен типаж 25-летней блондинки - специалистки по ядерной физики или другим сопоставимым наукам. ИИ сегодня играет роль этой блондинки, которая талантлива во всем, но теряется в трех соснах. И оабота с ИИ требует роста экспертных знаний: одно дело проверять и править ошибки за студентом, примерно зная, где он может накосячить, и другое дело - за самоуверенной ядерной блондинкой, потому что она точно накосячит, но где именно, не каждый сможет вовремя заметить.
Классная статья! Но с идей, что у llm-ок получается более менее норм создавать архитектуру - вообще не согласен. Имхо цель хорошей архитектура кода - максимизировать поддерживаемость/понятность кода. Сюда входит разбиение на удобные абстракции, продумывание зависимостей между компонентами.
То что обычно к арихитектуре не относят, но то что тоже очень сильно влияет на читаемость кода: удачно выбранные названия сущностей, аннотации типов (в контексте python), там где не хватает названий и аннотаций - докстринги.
Вот со всем этим в сумме у llm-ок большая беда. Запутанная декопозиция, переплетенные зависимости; Неиспользуемые функции / аргументы / переменные; То что должно быть аргументом - захардкожено, а то, что можно было бы и захардкодить передаем аргументом; Динамические данные в глобальных переменных, при этом константы зачем-то обернуты функциями; Аннотаций типов по умолчанию нет, а если просить добавить, то они нечитаемые (потому что см. неправильная декомпозиция); тонны дублирования, и т.д. Конечно всё это не в каждом куске выдаваемого кода, но довольно часто.
По моему опыту довести до ума то, что выдает условный джун, зачастую гораздо проще чем разобраться с тем что выдают llm-ки (конечно сильно зависит от джуна). У llm-ок настолько спагетти код выходит, что я просто отчаялся пытаться "навайбкодить" что-то, что выходит за рамки одной функции.
При этом llm-ки отличный инструмент, ежедневно пользуюсь, но всегда приходится держать в уме, что чем объемнее задача, тем нелинейно сложнее потом будет фиксить архитектуру и прочие моменты.
Чел засрал LLM при этом статью написала LLM, можно расходиться.
Блин... мне это нравится! "Я попросил написать простой проект и теперь знаю как работает LLM".
Да ни черта ты не знаешь. Я вот с помощью ИИшки пишу игрушку уже третий месяц. Размер проекта перевалил за 30К строк кода и ИИшка начала постоянно забывать а что там в других файлах.
Мне регулярно приходится скидывать в запрос .h файлы, чтобы тупо напомнить а чё там вообще есть. Даже если тот класс не менялся уже месяц как.
И вот это вот - основная проблема. Перечитать за ИИшкой - проще простого, посмотреть где оно там что накодит.
Ещё бесит постоянное смешение стилий написания. Я вроде как вынес код стайл в параметры проекта, но не помогает.
Ошибки достаточно легко фиксятся, это тоже не проблема. В конце концов, не ошибается только тот кто ничего не делает.
Ещё задалбывает постянно писать в запросе - "если остались вопросы - задавай прежде чем кодить".
Потому что уточнения, как правило, меньше по объёму чем код и пофиксить их лучше чем фиксить код.
Вообще, есть как бы три состояния работы с ИИ:
1. простая задача конвертации - чаще всего справляется на ура. Задачу типа "напиши утилиту, чтобы вытаскивать данные из xmls в json такого-то формата" пишет просто в лёт.
2. хорошо расписанный таск с кучей пунктов. Если у вас более ста пунктов, начинает ошибаться.
3. Постоянно дополняющийся проект без возможности написать отдельные модули.
Ну и как бы в каждом случае свои нюансы работы с LLM. И не надо говрить, что один-единственный кейс способен покрыть все аспекты работы.
Я веб программист и пишу совсем несложные вещи. И вот я уже вайб кодер и этот Куроср не может найти ошибку. Я ее уже вижу. Опять не может, предалагает уже совсем экзотику, шаманские камлания, бубен. И тогда я ему говорю, что типа инициализируй переменные и начинай работать интерпретатором, буквально строчка за строчкой и переменные сюда пиши в наш чат. Короче он секунд через 20 нашел эту ошибку. И еще сделал одно полезное замечание. Я так понял, что его можно заставить "думать". Возможно это дорого стоит и он старается съэкономить
Мне это напоминает хороший такой рандом. Повезло - получил код без ошибок. Не повезло, чуть-чуть ошибся в промте - получай полную ерунду. Я веб-разработчик, но вот понадобилось мне найти библиотеки расчёта лунных дней, восхода Луны, захода, полнолуния и так далее. ChatGPT глючил страшно: указывал несуществующие библиотеки, писал какую-то чушь, выдававшую неверные результаты.
Решила доверить ему занудное переписывание шаблонов с табличной верстки под div'ы (чтобы не отдавать фронтендерам) - выкинул половину файла почему-то.
Регулярно глючит в ответах на вопросы, например, по SQL. Пишу - запрос такой-то, напиши для Postgres такой-то версии. Использует функции, которых в Postgres в принципе нет. И потом это "ой, да, ты совершенно верно заметила".
В общем, иногда помогал, иногда без него я справилась бы гораздо быстрее, только время зря потратила.
Джун наоборот или разоблачение главного мифа вайб-кодинга