Это то, что на самом деле нужно уже много лет умному дому. Именно область автоматизированных домов имхо очень сильно страдала от большой сложности настройки сценария для рядового пользователя. А в смартфонах особо автоматизировать то нечего.
Я думаю тут есть интересный нюанс. Недавно на Хабре была статья от человека, который в академических целях разрабатывал своего кодинг агента (аналог codex/clode но своими руками), и он утверждал, что длительная донастройка требуется даже при переключении между gpt-5.2/5.3-codex, и падение качества существенное, а при переходе между сетками ещё более существенное. Так-что высока вероятность, что просто роутер между разными llm - это меньшая проблема, а большая - под поведение новой llm подстроиться.
Сегодня код работает за константное время, завтра за квадратичное. Сегодня без side эффектов, завтра с промежуточными файлами. Сегодня интерфейс выглядит консистентентно, завтра на каждом экране свои формы.
Команды вроде «поставь таймер», «сделай громче», «включи следующий трек» — это их естественная среда. Всё, что выходит за рамки простых действий, быстро превращается в «Извините, не могу с этим помочь...».
Ну вот это-же просто неправда. В рамках одного запроса та-же Алиса может последовательно ввести диалог и отвечать на постоянные вопросы весьма неплохо. Может не на уровне chatgpt/deepseek, но далеко не ограничиваясь только заготовленными командами.
Как будто если не указано квантование - значит использовались максимально большие неквантованные модели. Но то, что по хорошему лучше ясно указать чем не указать - согласен
Полностью поддерживаю. Codex был замечен в каскадном увеличении кода - когда ты ставишь ему задачу добавить "поддержку нового типа в карточккх" - условно, и на деле нужно добавить подтип данных, а он копирует всю карточку целиком, и большую часть обвязки, а точки входа обмазывает if (type ==1) if (type == 2).
Круто конечно, что итоговый код может даже работать и тесты выполнять, но уже через 5 итераций он может так распухнуть, что никаких токенов не хватит.
1. Квантовая механика и специальная теория относительности поспорили бы с вами на поприще того, что "все знали и так и оказалось". До сих пор люди с трудом воспринимают СТО, сжатие пространства при движении, и пертурбации со скоростью течения времени (и даже используют две абстракции - электрическое и магнитное поле, хотя второе - следствия действия СТО на первое, но тут ок, это модель и так легче).
Туда-же про точно верные ограничения, у нас даже базовые абстракции такие как время, скорость и расстояние, могут быть неверные.
2. У нейросетей есть вторая, более серьезная и неявная проблема - неверные аналогии. Нейросети стремятся интерполировать имеющиеся данные на неизвестные, например "в прошлом году была весна, значит в этом будет", и в целом, это рабочая стратегия для выживания. Но человек который знает всё про медицину, может "срезать путь" и сделать вывод в другой области, используя похожую медицинскую аналогию. А она может быть трижды очевидной и столько-же раз неверной.
Так-же и AI - на основе нейросетей - может и будет использовать аналоги из всех выученных областей данных для решения проблем, и чем больше он их знает и глубже анализ - тем больше вероятность, что он в логической цепочке использует недопустимый вывод т.к. то, что работает в классической механике, не работает в квантовой, а что работает в общей химии, не работает на огромных или слишком малых масштабах.
Т.е. больше знаний не гарантированно дают лучший результат, линейность этого процесса ещё необходимо доказать, и есть причины предполагать, что закон там другой - больше знаний до некоторого порога улучшают результат, а после ухудшают зашумливая ответ (гениальность не просто так делает людей странными и порой безумными).
И тогда - нам нужна не одна сеть, что знает всё, а набор сетей обученных до уровня максимальной эффективности, но с дырками в разных областях и алгоритмом консенсуса (мы уже к этому и пришли на сетях moex) - но тут как раз встаёт проблема того, где должны быть эти дырки в знаниях, чтобы совершить открытие. И есть нулевая вероятность - что распределение там например случайное, и если бы энтейн был экспертом ещё и по судебному праву, то никогда бы не открыл СТО, потому что в его голове сама идея законов и времени выглядели бы фундаментально иначе.
Вот ключевая проблема, про которую я упомянул. Есть высокая вероятность, что чтобы сделать новое открытие - нужно не только что-то знать, но и чего-то незнать. Если текущие знания человечества содержат ошибки, неверные аксиомы и неприменимым логические аналогии - то ии со всеми знаниями мира - может оказаться неэффективен, а результат даст только убирание из его памяти каких-то данных, а каких, мы сможем узнать только полным перебором.
Можно запустить 2-4-10 изолированных копии проекта, напряч в каждой копии агента что-то делать, по мере завершения работы - посмотреть изменения, и тут-же подлить их себе изменения в обычной студии. Тут речь про многозадачность
Идея проста на самом деле - у тебя есть основная ide - где ты подливаешь, смерживаешь и полируешь результаты работы агентов, а есть вот эта на втором экране, которая может тебе запустить сколько угодно изолированных друг от друга веток, и ты можешь натравить на каждую по ai агенту, чтобы он решал там какую-то подзадачу. В целом, я бы попробовал, особенно с учётом, что в android studio они что-то сломали, и теперь у меня не открывается две копии одного проекта одновременно изолированно (даже если они в разных папках лежат) - переключение ветки в одном проекте, переключает ветку в другом. Но тут нужен бесплатный период, чтобы понять - надо ли оно вообще
До сих пор остаётся незакрытым вопрос - вообще фундаментально, на уровне законов реальности - до какого предела можно увеличить скорость научных исследований (и вообще продается ли она значительному увеличению).
Если считать - что научное открытие - это результат получения из неполных данных о модели - полные, а одно из свойств информации - невозможность сжать данные со случайными распределением, то выходит - что если научные знания - имеют случайное распределение (что очевидно вероятно не совсем так) - то единственный метод получить из неполных данных - полные - полный перебор.
Для биологических учёных - это будет означать, что помимо знаний, на результат будут влиять не меньше - незнания (условно когда учёный не знает факт, который все считают само собой разумеющимся, и делает открытие, поставив эксперемент, результат которого считается предопределённым).
Понятно, что научнык данные - имеют отличное от белого шума распределение (хотя и это не факт, потому, что мы не знаем, сколько не знаем, а судить о распределении по части выборки - не всегда верно), но даже если они имеют некоторое особенное распределение - степень эффективности методики по логическому анализу всё равно строго ограничена некоторым пределом, когда придет время делать полный перебор эксперементально.
Есть ненулевая вероятность, что даже самые гениальный AI (настоящий AI) не даст значительного прироста в скорости открытый, т.к. нужно будет помимо гениального ai - ещё и 100 миллионов эксперементов.
Я знал, я был уверен, что все эти AI агенты такие кривые и глючные потому, что написаны без сами собой "пишет весь код OpenClaw с помощью Codex". Вот почему скорее всего все kilo code, Coda и прочие расширения - вечно сыпят ошибками, кладут студию, зацикливаются и такие кривые.
Я каждую волну llm кодинга пытаюсь завалить мир сгенерированными приложениями (пока вообще не выходит). Расскажу свои выводы.
По плюсам
Llm почти всегда круто реализовывают локализованные задачи. Написать утилиту, скрипт, поправить вёрстку, обновить компонент, написать тест - очень круто. В этих задачах экономия времени прямо реально до 10 раз и больше.
Llm неплохо объясняют код. Если где-то непонятное поведение или надо исправить - есть шанс в половину, что llm даст хорошую наводку на причину проблемы.
Можно быстро раскатать mvp.
А теперь о проблемах
Агенты - чудовищные пожиратели токенов. Когда я использовал бесплатное api со скоростью инференса 50 токенов, на задачу которая решается за 1.5 часа ручного кодинга ушло ~48 часов непрерывной работы агента. Причем задача решена не была, только частичные наработки, которые надо допиливать напильником. И у меня есть ощущение, что на проверки - не помер ли агент в процессе и что он так долго делает - я потратил половину времени от ручного написания кода)
Llm ужасны в нелокализованных задачах. Дайте агенту обширную задачу требующую внести изменения в несколько файлов - и он перечитает их по 10 раз, и перепишет в 5 раз больше чем нужно, зачастую сломав что-то другое, что до этого работало. Я уже видел задачи, когда проблема решалась точечным изменением одного флага, а llm переписывала 800 строк кода.
Llm вообще не знает что такое производительность. Там, где агент писал мне решение, которое почти работало (и правкой импортов, мелочей и пары условий - завелось), я получил 6 кадров на сцене, которая не нёсет никакой нагрузки. Я попросил оптимизировать, и он оптимизировал, но вообще не то, что на самом деле жрало ресурсы. Пол часа напильника, и 6 фпс превратились в 120, но для этого надо понимать код. Оптимизировать написанный код - может быть значительно сложнее, чем написать оптимальный сразу, особенно когда проблемы ты находишь не сразу, а когда сверху ещё 20 зависимостей и сотни строк кода.
Ну и главная проблема - в один прекрасный момент агенты даже, блин, на микроскопической кодовой базе - впадают в тупняк. Они начинают ходить по файлам кругами, переживая контекст и повторяя круг, переписывают одни и те же параметры также обратно, ломают по очереди две фичи туда обратно, чиня одну и ломая вторую, или пишут семиступечантые вундервафли там, где нужно сделать что-то очень простое. И вот когда у тебя один - два новых класса и ты сталкиваешься с проблемой - можно спасти бедолагу руками. Но когда у тебя 100к строк кода, с архитектурой от llm (у меня в одном проекте например агент использовал 3 разных подхода к di в разных классах и 2 к построению интерфейса, и смешал несколько архитектур), то исправить одну протекающую проблему - может занять недели или месяцы.
Пока - по ощущениям, llm в качестве кодера - это как болиды формулы 1. Они очень быстрые, очень красивые, громко звучат, но на треке. И чем дальше ты от идеального трека к суровой реальности, тем больше экспоненциально растут в тебя проблемы.
Так полыхают не потому, что не принимают новый инструмент, а потому, что им пытаются ссать в уши, что он работает намного лучше, чем оно есть по факту.
Я вот всеми руками за, чтобы я решал одну задачу в агент другую или 10, но что codex, что Клод, что chatgpt + kilo code - ну ни одну задачу продуктовую пока не смогли решить, ни с каким промптом. Ни декомпозированную, ни описанную, ни "как есть". Варят килотонны токенов, перечитывают десятки файлов проекта, и в конце составляют план из чуши или вносят изменения в файлы, которые вообще к делу отношения не имеют.
Да вот прямо час назад - я попросил deepseek в чате отцентровать элемент, и все что он сделал - описал какой он молодец и добавил в код комментарии. Комментарии Карл, без единой правки меняющий результат работы программы. Нет, конечно если по пытать его пол часика, он выдаст кривое решение, но я в коде это центрование напишу за три, просто я хотел за 10 секунд.
Ну не годятся пока инструменты, чтобы реально отказаться от знания кода, даже близко не похоже.
Тут как со статистикой. Не нужно даже врать - можно не договаривать. Нет ровным счётом ничего сложного в том, чтобы написать с нуля проект на сто миллионов строк кода ии агентом. Например если твоя задача типична и часто встречалась (например сделать 100500 мини игр в одной), или есть твоё ТЗ уже на сто миллионов строк кода, и главное, если каждый новый блок кода мало взаимодействует с остальным. Например можно нагенерировать какой нибудь декодер кучи форматов, где связанная часть - чисто один файл с выбором in/out, а остальное - раздельные атомарные декодеры.
Проблемы у llm начинаются когда тебе надо не написать проект с нуля а внести правку в существующую многоступенчатую систему. У меня codex на бесплатном api со скоростью инференса 50 токенов в секунду - 6 часов варил одну очевидную строку кода (я решил просто проверить, а не сделал сам)
По моему опыту код до 500 строк получается с первого прогона, от 500 до 1000 2-3 прогона
Пфф, да это вообще легко, вы мне скажите с какого прогона получается внести точечные изменения в этот код из 500строк. Я вот даже на микроскопическом пет проекте, в целях эксперемента, из 4х фич с помощью агента и топовой llm смог реализовать только 1 (как раз ту, где 90% - код с нуля, и 10% использование существующего), и то самую простую. На остальных начинались свистопляски с ломанием базы данных, других частей кода, или зацикливание.
Код полностью описан на уровне технического задания для LLM
Ах если бы оно так работало, то моя задача - добавить новый тип тренировки для кардио в моё пет приложение уже была бы готова. На деле, оно варит проект дольше, чем я бы написал этот код, а в результирующем плане предлагает столько изменений которые не нужны для задачи, что потом ещё десять итераций потребуется чтобы их исправить.
Не сами языки детерминированы и формализованы а их поведение и конечный результат.
Это в корне меняет дело. Ведь если я до этого говорил, о том, что вы пишете на ЯП и получаете однозначно понятный результат, то теперь то значит, что вы пишите на ЯП и получаете однозначно понятный во результат).
В индустрии целые виды фреймворков (rect, compose) и инструментов (docker) и функциональное программирование целиком, сложились ради того, чтобы исключить состояние, потому что состояние сложно контролировать.
А теперь у нас за состояние (код) - будет отвечать ещё и инструмент, который сам вносит море неопределённости. Покрыть все тестами - это конечно звучит как план, только кто все эти тесты напишет, придумает и проверит? Вот у меня llm написала (с некоторыми правками от меня) исполняемый код, он даже решает поставленную задачу, только вместо 120 - выдает 6 кадров, это значит тестами надо крыть не только данные/результат, но и производительность. А если она падает на специфических данных/по памяти/после 100 прогонов.
Нет, как инструмент помощи и решения локальных микрозадач или тревиальных сценариев - ок, как замена ЯП - это яйцо настолько сырое, что ещё не родилась курица которая должна его снести.
В целом, llm агенты неплохи и реально могут поднять производительность - когда ты берешь на себя сложную работу, а на втором экране даёшь агенту небольшую другую задачу (или анализ другой большой задачи). Я так делаю с локальной поднятой qwen3-coder. Сам беру комплексные задачи, а кнопки перекрасить, дизайн подвигать, или найти откуда прилетает параметр - отдаю агенту. Когда он выдает результат - тратишь 2 минуты на ревью, и отправляешь на следующую задачу или на новую итерацию по той-же.
Но комплексные и сложные задачи даже Клод решает пока настолько плохо, что количество итераций и сложность написания тех задания сводит пользу такого подхода на ноль
Это то, что на самом деле нужно уже много лет умному дому. Именно область автоматизированных домов имхо очень сильно страдала от большой сложности настройки сценария для рядового пользователя. А в смартфонах особо автоматизировать то нечего.
Я думаю тут есть интересный нюанс. Недавно на Хабре была статья от человека, который в академических целях разрабатывал своего кодинг агента (аналог codex/clode но своими руками), и он утверждал, что длительная донастройка требуется даже при переключении между gpt-5.2/5.3-codex, и падение качества существенное, а при переходе между сетками ещё более существенное. Так-что высока вероятность, что просто роутер между разными llm - это меньшая проблема, а большая - под поведение новой llm подстроиться.
Сегодня код работает за константное время, завтра за квадратичное. Сегодня без side эффектов, завтра с промежуточными файлами. Сегодня интерфейс выглядит консистентентно, завтра на каждом экране свои формы.
Ну вот это-же просто неправда. В рамках одного запроса та-же Алиса может последовательно ввести диалог и отвечать на постоянные вопросы весьма неплохо. Может не на уровне chatgpt/deepseek, но далеко не ограничиваясь только заготовленными командами.
Ооо, гиганское спасибо и плюс в карму, я что-то даже и не сообразил, а дело видимо действительно в этом. Ну, теперь и отдельная ide не так уж нужна)
Как будто если не указано квантование - значит использовались максимально большие неквантованные модели. Но то, что по хорошему лучше ясно указать чем не указать - согласен
Полностью поддерживаю. Codex был замечен в каскадном увеличении кода - когда ты ставишь ему задачу добавить "поддержку нового типа в карточккх" - условно, и на деле нужно добавить подтип данных, а он копирует всю карточку целиком, и большую часть обвязки, а точки входа обмазывает if (type ==1) if (type == 2).
Круто конечно, что итоговый код может даже работать и тесты выполнять, но уже через 5 итераций он может так распухнуть, что никаких токенов не хватит.
Хотя может у опуса с этим дела лучше.
1. Квантовая механика и специальная теория относительности поспорили бы с вами на поприще того, что "все знали и так и оказалось". До сих пор люди с трудом воспринимают СТО, сжатие пространства при движении, и пертурбации со скоростью течения времени (и даже используют две абстракции - электрическое и магнитное поле, хотя второе - следствия действия СТО на первое, но тут ок, это модель и так легче).
Туда-же про точно верные ограничения, у нас даже базовые абстракции такие как время, скорость и расстояние, могут быть неверные.
2. У нейросетей есть вторая, более серьезная и неявная проблема - неверные аналогии. Нейросети стремятся интерполировать имеющиеся данные на неизвестные, например "в прошлом году была весна, значит в этом будет", и в целом, это рабочая стратегия для выживания. Но человек который знает всё про медицину, может "срезать путь" и сделать вывод в другой области, используя похожую медицинскую аналогию. А она может быть трижды очевидной и столько-же раз неверной.
Так-же и AI - на основе нейросетей - может и будет использовать аналоги из всех выученных областей данных для решения проблем, и чем больше он их знает и глубже анализ - тем больше вероятность, что он в логической цепочке использует недопустимый вывод т.к. то, что работает в классической механике, не работает в квантовой, а что работает в общей химии, не работает на огромных или слишком малых масштабах.
Т.е. больше знаний не гарантированно дают лучший результат, линейность этого процесса ещё необходимо доказать, и есть причины предполагать, что закон там другой - больше знаний до некоторого порога улучшают результат, а после ухудшают зашумливая ответ (гениальность не просто так делает людей странными и порой безумными).
И тогда - нам нужна не одна сеть, что знает всё, а набор сетей обученных до уровня максимальной эффективности, но с дырками в разных областях и алгоритмом консенсуса (мы уже к этому и пришли на сетях moex) - но тут как раз встаёт проблема того, где должны быть эти дырки в знаниях, чтобы совершить открытие. И есть нулевая вероятность - что распределение там например случайное, и если бы энтейн был экспертом ещё и по судебному праву, то никогда бы не открыл СТО, потому что в его голове сама идея законов и времени выглядели бы фундаментально иначе.
Вот ключевая проблема, про которую я упомянул. Есть высокая вероятность, что чтобы сделать новое открытие - нужно не только что-то знать, но и чего-то незнать. Если текущие знания человечества содержат ошибки, неверные аксиомы и неприменимым логические аналогии - то ии со всеми знаниями мира - может оказаться неэффективен, а результат даст только убирание из его памяти каких-то данных, а каких, мы сможем узнать только полным перебором.
Можно запустить 2-4-10 изолированных копии проекта, напряч в каждой копии агента что-то делать, по мере завершения работы - посмотреть изменения, и тут-же подлить их себе изменения в обычной студии. Тут речь про многозадачность
Идея проста на самом деле - у тебя есть основная ide - где ты подливаешь, смерживаешь и полируешь результаты работы агентов, а есть вот эта на втором экране, которая может тебе запустить сколько угодно изолированных друг от друга веток, и ты можешь натравить на каждую по ai агенту, чтобы он решал там какую-то подзадачу. В целом, я бы попробовал, особенно с учётом, что в android studio они что-то сломали, и теперь у меня не открывается две копии одного проекта одновременно изолированно (даже если они в разных папках лежат) - переключение ветки в одном проекте, переключает ветку в другом. Но тут нужен бесплатный период, чтобы понять - надо ли оно вообще
До сих пор остаётся незакрытым вопрос - вообще фундаментально, на уровне законов реальности - до какого предела можно увеличить скорость научных исследований (и вообще продается ли она значительному увеличению).
Если считать - что научное открытие - это результат получения из неполных данных о модели - полные, а одно из свойств информации - невозможность сжать данные со случайными распределением, то выходит - что если научные знания - имеют случайное распределение (что очевидно вероятно не совсем так) - то единственный метод получить из неполных данных - полные - полный перебор.
Для биологических учёных - это будет означать, что помимо знаний, на результат будут влиять не меньше - незнания (условно когда учёный не знает факт, который все считают само собой разумеющимся, и делает открытие, поставив эксперемент, результат которого считается предопределённым).
Понятно, что научнык данные - имеют отличное от белого шума распределение (хотя и это не факт, потому, что мы не знаем, сколько не знаем, а судить о распределении по части выборки - не всегда верно), но даже если они имеют некоторое особенное распределение - степень эффективности методики по логическому анализу всё равно строго ограничена некоторым пределом, когда придет время делать полный перебор эксперементально.
Есть ненулевая вероятность, что даже самые гениальный AI (настоящий AI) не даст значительного прироста в скорости открытый, т.к. нужно будет помимо гениального ai - ещё и 100 миллионов эксперементов.
Я знал, я был уверен, что все эти AI агенты такие кривые и глючные потому, что написаны без сами собой "пишет весь код OpenClaw с помощью Codex". Вот почему скорее всего все kilo code, Coda и прочие расширения - вечно сыпят ошибками, кладут студию, зацикливаются и такие кривые.
Число бесплатных пользователей из Пентагона выросло в два раза))
Я каждую волну llm кодинга пытаюсь завалить мир сгенерированными приложениями (пока вообще не выходит). Расскажу свои выводы.
По плюсам
Llm почти всегда круто реализовывают локализованные задачи. Написать утилиту, скрипт, поправить вёрстку, обновить компонент, написать тест - очень круто. В этих задачах экономия времени прямо реально до 10 раз и больше.
Llm неплохо объясняют код. Если где-то непонятное поведение или надо исправить - есть шанс в половину, что llm даст хорошую наводку на причину проблемы.
Можно быстро раскатать mvp.
А теперь о проблемах
Агенты - чудовищные пожиратели токенов. Когда я использовал бесплатное api со скоростью инференса 50 токенов, на задачу которая решается за 1.5 часа ручного кодинга ушло ~48 часов непрерывной работы агента. Причем задача решена не была, только частичные наработки, которые надо допиливать напильником. И у меня есть ощущение, что на проверки - не помер ли агент в процессе и что он так долго делает - я потратил половину времени от ручного написания кода)
Llm ужасны в нелокализованных задачах. Дайте агенту обширную задачу требующую внести изменения в несколько файлов - и он перечитает их по 10 раз, и перепишет в 5 раз больше чем нужно, зачастую сломав что-то другое, что до этого работало. Я уже видел задачи, когда проблема решалась точечным изменением одного флага, а llm переписывала 800 строк кода.
Llm вообще не знает что такое производительность. Там, где агент писал мне решение, которое почти работало (и правкой импортов, мелочей и пары условий - завелось), я получил 6 кадров на сцене, которая не нёсет никакой нагрузки. Я попросил оптимизировать, и он оптимизировал, но вообще не то, что на самом деле жрало ресурсы. Пол часа напильника, и 6 фпс превратились в 120, но для этого надо понимать код. Оптимизировать написанный код - может быть значительно сложнее, чем написать оптимальный сразу, особенно когда проблемы ты находишь не сразу, а когда сверху ещё 20 зависимостей и сотни строк кода.
Ну и главная проблема - в один прекрасный момент агенты даже, блин, на микроскопической кодовой базе - впадают в тупняк. Они начинают ходить по файлам кругами, переживая контекст и повторяя круг, переписывают одни и те же параметры также обратно, ломают по очереди две фичи туда обратно, чиня одну и ломая вторую, или пишут семиступечантые вундервафли там, где нужно сделать что-то очень простое. И вот когда у тебя один - два новых класса и ты сталкиваешься с проблемой - можно спасти бедолагу руками. Но когда у тебя 100к строк кода, с архитектурой от llm (у меня в одном проекте например агент использовал 3 разных подхода к di в разных классах и 2 к построению интерфейса, и смешал несколько архитектур), то исправить одну протекающую проблему - может занять недели или месяцы.
Пока - по ощущениям, llm в качестве кодера - это как болиды формулы 1. Они очень быстрые, очень красивые, громко звучат, но на треке. И чем дальше ты от идеального трека к суровой реальности, тем больше экспоненциально растут в тебя проблемы.
Так полыхают не потому, что не принимают новый инструмент, а потому, что им пытаются ссать в уши, что он работает намного лучше, чем оно есть по факту.
Я вот всеми руками за, чтобы я решал одну задачу в агент другую или 10, но что codex, что Клод, что chatgpt + kilo code - ну ни одну задачу продуктовую пока не смогли решить, ни с каким промптом. Ни декомпозированную, ни описанную, ни "как есть". Варят килотонны токенов, перечитывают десятки файлов проекта, и в конце составляют план из чуши или вносят изменения в файлы, которые вообще к делу отношения не имеют.
Да вот прямо час назад - я попросил deepseek в чате отцентровать элемент, и все что он сделал - описал какой он молодец и добавил в код комментарии. Комментарии Карл, без единой правки меняющий результат работы программы. Нет, конечно если по пытать его пол часика, он выдаст кривое решение, но я в коде это центрование напишу за три, просто я хотел за 10 секунд.
Ну не годятся пока инструменты, чтобы реально отказаться от знания кода, даже близко не похоже.
Тут как со статистикой. Не нужно даже врать - можно не договаривать. Нет ровным счётом ничего сложного в том, чтобы написать с нуля проект на сто миллионов строк кода ии агентом. Например если твоя задача типична и часто встречалась (например сделать 100500 мини игр в одной), или есть твоё ТЗ уже на сто миллионов строк кода, и главное, если каждый новый блок кода мало взаимодействует с остальным. Например можно нагенерировать какой нибудь декодер кучи форматов, где связанная часть - чисто один файл с выбором in/out, а остальное - раздельные атомарные декодеры.
Проблемы у llm начинаются когда тебе надо не написать проект с нуля а внести правку в существующую многоступенчатую систему. У меня codex на бесплатном api со скоростью инференса 50 токенов в секунду - 6 часов варил одну очевидную строку кода (я решил просто проверить, а не сделал сам)
Пфф, да это вообще легко, вы мне скажите с какого прогона получается внести точечные изменения в этот код из 500строк. Я вот даже на микроскопическом пет проекте, в целях эксперемента, из 4х фич с помощью агента и топовой llm смог реализовать только 1 (как раз ту, где 90% - код с нуля, и 10% использование существующего), и то самую простую. На остальных начинались свистопляски с ломанием базы данных, других частей кода, или зацикливание.
Ах если бы оно так работало, то моя задача - добавить новый тип тренировки для кардио в моё пет приложение уже была бы готова. На деле, оно варит проект дольше, чем я бы написал этот код, а в результирующем плане предлагает столько изменений которые не нужны для задачи, что потом ещё десять итераций потребуется чтобы их исправить.
Это в корне меняет дело. Ведь если я до этого говорил, о том, что вы пишете на ЯП и получаете однозначно понятный результат, то теперь то значит, что вы пишите на ЯП и получаете однозначно понятный во результат).
В индустрии целые виды фреймворков (rect, compose) и инструментов (docker) и функциональное программирование целиком, сложились ради того, чтобы исключить состояние, потому что состояние сложно контролировать.
А теперь у нас за состояние (код) - будет отвечать ещё и инструмент, который сам вносит море неопределённости. Покрыть все тестами - это конечно звучит как план, только кто все эти тесты напишет, придумает и проверит? Вот у меня llm написала (с некоторыми правками от меня) исполняемый код, он даже решает поставленную задачу, только вместо 120 - выдает 6 кадров, это значит тестами надо крыть не только данные/результат, но и производительность. А если она падает на специфических данных/по памяти/после 100 прогонов.
Нет, как инструмент помощи и решения локальных микрозадач или тревиальных сценариев - ок, как замена ЯП - это яйцо настолько сырое, что ещё не родилась курица которая должна его снести.
В целом, llm агенты неплохи и реально могут поднять производительность - когда ты берешь на себя сложную работу, а на втором экране даёшь агенту небольшую другую задачу (или анализ другой большой задачи). Я так делаю с локальной поднятой qwen3-coder. Сам беру комплексные задачи, а кнопки перекрасить, дизайн подвигать, или найти откуда прилетает параметр - отдаю агенту. Когда он выдает результат - тратишь 2 минуты на ревью, и отправляешь на следующую задачу или на новую итерацию по той-же.
Но комплексные и сложные задачи даже Клод решает пока настолько плохо, что количество итераций и сложность написания тех задания сводит пользу такого подхода на ноль
В статье упоминается про размывание ролей - как code review будет делать менеджер или дизайнер?)