а нет идеальной модели сейчас. И o3 и Gemini 2.5 и Claude 3.7 уже умеют работать с огромным кодом на десятки файлов. Но у всех есть нюансы. Claude 3.7 всё-таки лучше себя показывает на маленьком контексте, Gemini отлично понимает большой контекст и сложные задачи, но часто пишет избыточный код. o3 я сегодня потестил, у него ответы гораздо более понятные и лаконичные, чем у Gemini, но на большом контексте ошибается и хуже понимает задачу. И ещё забавно оправдывается, когда ошибается. Так что я пока кормлю задачу всем трём моделям и сравниваю.
В таком случае в автобусе могло бы быть минимум 5 человек (только пассажиры в последних двух рядах).
Однако, я полагаю, что классическая интерпретация подобных задач всё же предполагает наличие водителя за рулём функционирующего транспортного средства. Но ваше замечание вполне обоснованно с точки зрения логики и современных технологических возможностей.
Очевидно, статья написана не без помощи нейросети – стиль GPT трудно с чем-то спутать.
Да, это действительно так, я и не пытался уйти от типичного GPT-стиля здесь, так как он даёт хорошую структуру. И вы правы, несмотря на то, что работа GPT здесь скорее стилистическая, чем смысловая (сам бы я так складно не написал), всё равно получилось смещение акцентов. Изначально статья задумывалась скорее, как размышления, чем как какие-то однозначные утверждения, но GPT придал статье излишней уверенности и безапелляционности, которую я изначально не закладывал. Какие-то вещи упростились с искажением смысла (следствие из алгоритмической сложности местами превратилось в равенство), а некоторые мысли, которые я хотел донести, оказались потерянными.
А с колмогоровской сложностью всё наоборот: низкоэнтропийные состояния более вероятны за счёт алгоритмических закономерностей (их проще описать)
Здесь я бы не ставил равенство между этими двумя смыслами, хотя могу ошибаться. То, что низкосложные состояния проще описать короткой программой не значит, что они более вероятны при случайном выборе. Высокоэнтропийные состояния сложнее описать, но они более вероятны, так как их большинство. Клеточные автоматы, если мы берём не примитивные, а универсальные, (ну или другие вычисления) могут краткосрочно застревать на низкоэнтропийных уровнях, но долгосрочно сложность состояния должна возрастать, особенно если есть постоянные квантовые флуктуации. Плюс мы можем вернуться к антропному принципу: в застрявших на низкоэнтропийном состоянии Вселенных просто нет условий для существования наблюдателей.
Я в последней статье пришёл к тому же выводу в контексте проблемы больцмановского мозга. На первый взгляд всё сходится: низкая энтропия ранней вселенной – низкая колмогоровская сложность, высокая энтропия больцмановского мозга – высокая колмогоровская сложность.
Прочитал статью. Очень элегантный переход. Единственное, что меня смущает в больцмановских мозгах - мы не знаем что такое сознание. Можно сказать, что это всё философия, но раз уж мы привлекаем нашу субъективную реальность (наблюдение) для описания, странно было бы игнорировать природу сознания. И здесь всё зависит от подхода в философии сознания. Если мы берём за основу физикализм и редукционизм, то да, мы можем считать, что больцмановский мозг имеет сознание, в функционализме сознание может требовать устойчивых причинно-следственных связей с окружающим миром, которых у больцмановского мозга нет, а в дуализме больцмановский мозг будет являться философским зомби, то есть мы не сможем им оказаться. Но вообще статья выглядит очень убедительно.
Ну да. Плохой архиватор даст высокую сложность даже для простых данных, а идеальный теоретически может сжать любое состояние до "шаг N в системе S". Но идеальный архиватор же переносит сложность в себя. Чем специфичнее закономерности, которые он умеет распознавать, тем сложнее сам архиватор. Его собственная сложность будет приближаться к сложности описываемых процессов, мы просто переносим сложность в архиватор, а не избавляемся от неё. Плюс даже зная точные формулы, обычно нельзя перескочить вычисления, каждый шаг нужно выполнить. Для хаотических систем вообще нет короткого пути - состояние через N шагов можно получить только последовательно. То есть опять же, либо мы переносим сложность в архиватор, либо рассматриваем какие-то очень специфичные случаи, которые могут быть применены к отдельным сценариям клеточных автоматов, но вряд ли - к эволюции Вселенной.
и сюда же ещё эту статью скину, чуток упоминал её в предыдущем комментарии, но явно дополню со ссылкой. Здесь Вольфрам утверждает, что второй закон – это следствие вычислительной сложности: т.е. поскольку мы (ограниченные наблюдатели) не можем эффективно вычислить детальное поведение системы изнутри, нам оно выглядит случайным, и мы вводим энтропию как меру этой случайности. И хотя можно сконструировать вычислительные системы, демонстрирующие явное различие между микроскопическим описанием и генерирующим алгоритмом, в физических системах таких “подобранных” случаев практически не встретишь, а если и встретишь, они крайне маловероятны. Поэтому при изначально вычислительной природе Вселенной, второй закон в целом применительно к космологии работает хорошо, тем более, что у нас уже есть проверенные методы расчёта энтропии для физических систем, в отличие от более абстрактной меры вычислительной сложности.
А почему вы считаете, что я не отвечу? Ваше сравнение разбиралось и Стивеном Вольфрамом и например вот в этой сравнительно недавней статье. Да, из статьи может сложиться впечатление, что я чуть ли не уравниваю термодинамическую энтропию с колмогоровской сложностью, т.е. фактически термодинамическая энтропия = K(x). Но связь между этими величинами не настолько прямая.
В той же статье по алгоритмической термодинамике предлагается формула для алгоритмической энтропии состояния:
которая разделяет вклады логарифма меры и колмогоровской сложности. т.е., алгоритмическая энтропия учитывает не только сам алгоритм, порождающий состояние, но и статистическое множество микросостояний, к которому оно относится.
Представьте, что термодинамическая энтропия – это такая мера, которая зависит от того, как мы группируем все мельчайшие детали. То есть, она в какой-то мере субъективна - всё зависит от того, что именно мы считаем важным, а что можно упустить. А алгоритмическая сложность, по сути, показывает, насколько коротким может быть «рецепт» для создания конкретного состояния системы - и это более объективная характеристика.
Например, если у вас есть клеточный автомат, который генерирует узор, то, если вы знаете правило, начальное условие и номер шага, формально описание этого узора может быть очень компактным. То есть, по колмогоровской сложности оно простое. Но без знания этого правила узор для нас выглядит случайным и сложным - т.е. термодинамическая энтропия.
Стивен Вольфрам указывает на эту разницу: он говорит, что тут важно различать то, что мы видим (наблюдаемая случайность, которая отражается в статистической энтропии), и то, что на самом деле лежит в основе (простой алгоритм). Конечно, можно теоретически придумать вычислительные системы, которые «обращают» процесс и нарушают привычное направление второго закона, но в реальной физике такие случаи практически не встречаются - они слишком маловероятны.
Таким образом, разночтения между алгоритмической сложностью и термодинамической энтропией вовсе не опровергают идею, а скорее подчёркивают, что второй закон – это, в конечном счёте, статистическое правило для типичных систем. То есть, даже если формально узор может быть описан коротко, для нас он выглядит случайным, потому что мы не знаем сжатого описания. И возможно алгоритмическая энтропия может быть более фундаментальной, так как дает глубже представление о сложности системы Т.е. мне не кажется, что основная идея, возможность описания эволюции Вселенной как вычисления, описываемого в том числе алгоритмическим подходом к термодинамике здесь страдает. Но опять же, я не подаю эту идею как однозначную истину, однако если оно будет работать - последствия этого мне кажутся очень интересными.
в принципе, лечится языковыми реформами. Чем позже она была - тем ближе написание к произношению. Но если давно не проводить - да, придётся отдельно запоминать письменную форму слов, что недалеко от иероглифов.
В танцевальной мини-игре в клубе в GTA San Andreas представлены следующие треки:
"Running Away" от Roy Ayers
"Rock Creek Park" от The Blackbyrds
"Hot Pants" от Bobby Byrd
"Hollywood Swinging" от Kool & the Gang
"Love Rollercoaster" от Ohio Players
"Express Yourself" от Charles Wright & the Watts 103rd Street Rhythm Band
o3-mini:
В GTA San Andreas существует специальная миниигра – танцевальный конкурс в ночном клубе, где во время танца играют заранее зафиксированные треки.
• Один из трёх музыкальных треков, сопровождающих танцевальную миниигру – это композиция Kool & the Gang «Hollywood Swinging». Именно этот трек звучит, например, на втором уровне конкурса, и именно он часто упоминается фанатами как классика для такого мероприятия.
• Кроме «Hollywood Swinging» существуют ещё два трека, которые можно разблокировать по мере набора очков в миниигре. После успешного прохождения первого или второго этапа игрок получает возможность сыграть следующий трек – его часто называют «Funky» или дающим более зажигательный фанк, хотя точное название второго (и, возможно, третьего) трека может варьироваться в зависимости от версии игры и локализации.
Не в контексте, поэтому не могу оценить уровень галлюцинаций.
возможно для каких-то более специализированных вещей так и есть, но с веб-разработкой современные модели справляются очень хорошо. 50-60% случаев с косяками давно не наблюдаю, а если косяки и появляются довольно часто проблема в том, что я сам не точно сформулировал запрос.
Может быть и так. Сейчас очень сложно предположить каким именно будет рынок труда во время AGI. Один вариант - да, получится как с компьютеризацией, с помощью ИИ мы начнём открывать те области, которых пока нет (например, как появилась новая область по доставке продуктов или по обслуживанию IT-систем). Другой вариант - ИИ будет эффективно выполнять всю ту работу, что можно сейчас сделать условно на удалёнке, тогда этот труд или перетечёт во что-нибудь другое или нет. Но там полностью неизведанная территория, я не знаю как это прогнозировать.
А всё остальное - обычные навыки программирования, которые мы применяем на код ревью. Я к тому что дополнительного обучения совсем немного, а буст по скорости разработки уже значительный.
в краткосроке да. Задач всегда много, можно просто начать делать то, к чему раньше было не подступиться. Но мы только на самых ранних этапах, в дальнейшем традиционный кодинг может перейти во что-то совершенно другое.
делать подходящие промпты для ИИ, понимать какие там бывают галлюцинации и уметь их корректировать
это сильно менее квалифицированная работа, чем писать всё самому. Нейронки всё лучше и лучше понимают, что хочет пользователь. Это скорее сродни навыку "гуглить" и "смотреть stackoverflow", чем что-то, чему сложно обучиться.
Обычно такое лечится очень простыми промптами. Например, "давайте сперва продумаем оптимальную архитектуру, а потом напишем код", "напишем для окружения с такими-то версиями". Ну и писать все нюансы лучше заранее. В любом случае перед написанием кода и без LLM их надо будет продумать. Не обязательно как-то извращаться, максимально короткие фразы LLM отлично понимают. А про удаление частей кода - современные нейронки корёжат код всё реже и реже. Раньше это было проблемой, но не сейчас.
А зависимости от ChatGPT уже нет. Падает он не то что бы часто, так-то и прогер может заболеть. А если всё-таки упал - есть Claude, есть тот же DeepSeek на сторонних хостингах и т.д.
Не обязательно очень хорошо разбираться. Можно набросать прототип на не слишком знакомой тебе технологии. В прод код, который не понимаешь, конечно лучше не тащить, но чтобы проверить теорию, уже подходит отлично.
Понять когда LLM применимы, а когда пока ещё нет, довольно просто. Если я вижу задачу, которая проблемна для LLM, я просто делаю её сам, максимум делегирую нейронке бойлерплейт по ней. Было пара ситуаций, когда LLM предлагала изначально неверное решение, которое выглядело как верное, и чтобы понять что оно не сработает, уходило много времени. Но это скорее исключение, которое не перевешивало сэкономленное время на других задачах.
Кажется, что большинство комментаторов использовали какие-то старые версии LLM. За те два года, что я использую LLM в программировании я вижу очень большой прогресс. В GPT 3.5 даже на небольших задачах часто были галлюцинации. С o1/o3-mini-high, а иногда и с Claude 3.5 Sonnet я могу накинуть сразу несколько файлов для контекста, скопировать задачу из Jira и сказать "пиши". В большом проценте случаев ИИ напишет с первого раза как надо.
Да, LLM может что-то не учесть или использовать старую библиотеку, но это больше вопрос к промпту. Да, иногда было такое, что LLM с самого начала предлагала не самое оптимальное решение, и на его разбор мне приходилось тратить больше времени, чем если бы я написал сам. Но в основном нейросети мне в ежедневном режиме очень экономят время. Да, нужно ревьювить каждую строчку, но это в любом случае надо делать. А исправлять приходится всё меньше и меньше. Тут и нейросети вышли на новый уровень и я научился что, как и в каких случаях у них запрашивать.
Я не вижу причин, почему эта тенденция должна остановиться. Пока есть проблемы с большим контекстом и связкой с пользовательским опытом (LLM видит только код, но не интефейс продукта в динамике), но это не выглядит нерешаемым.
В краткосроке наверное ничего страшного не произойдёт. Программисты будут эффективнее, но задач много, можно будет просто начать делать те задачи, которые раньше не сходились по экономике, а теперь начнут сходиться.
Но в дальнейшем LLM вполне могут заменить не только джунов и мидлов, но и тимлидов, PM и т.д. Эта работа требует большей квалификации, происходит на более высоком уровне абстракции, но в целом такая же работа с данными, во что LLM умеют. Пока не так хорошо, как работать с атомарными задачами, но посмотрим что будет дальше.
этот переход не только к СССР относится, на графике это видно
да, но фильмы снимались прежде всего для показа в кинотеатрах.
а нет идеальной модели сейчас. И o3 и Gemini 2.5 и Claude 3.7 уже умеют работать с огромным кодом на десятки файлов. Но у всех есть нюансы. Claude 3.7 всё-таки лучше себя показывает на маленьком контексте, Gemini отлично понимает большой контекст и сложные задачи, но часто пишет избыточный код. o3 я сегодня потестил, у него ответы гораздо более понятные и лаконичные, чем у Gemini, но на большом контексте ошибается и хуже понимает задачу. И ещё забавно оправдывается, когда ошибается. Так что я пока кормлю задачу всем трём моделям и сравниваю.
Или хотя бы в интерфейсе GigaChat или YandexGPT.
ответ Claude:
Благодарю за очень интересный ответ!
Да, это действительно так, я и не пытался уйти от типичного GPT-стиля здесь, так как он даёт хорошую структуру. И вы правы, несмотря на то, что работа GPT здесь скорее стилистическая, чем смысловая (сам бы я так складно не написал), всё равно получилось смещение акцентов. Изначально статья задумывалась скорее, как размышления, чем как какие-то однозначные утверждения, но GPT придал статье излишней уверенности и безапелляционности, которую я изначально не закладывал. Какие-то вещи упростились с искажением смысла (следствие из алгоритмической сложности местами превратилось в равенство), а некоторые мысли, которые я хотел донести, оказались потерянными.
Здесь я бы не ставил равенство между этими двумя смыслами, хотя могу ошибаться. То, что низкосложные состояния проще описать короткой программой не значит, что они более вероятны при случайном выборе. Высокоэнтропийные состояния сложнее описать, но они более вероятны, так как их большинство. Клеточные автоматы, если мы берём не примитивные, а универсальные, (ну или другие вычисления) могут краткосрочно застревать на низкоэнтропийных уровнях, но долгосрочно сложность состояния должна возрастать, особенно если есть постоянные квантовые флуктуации. Плюс мы можем вернуться к антропному принципу: в застрявших на низкоэнтропийном состоянии Вселенных просто нет условий для существования наблюдателей.
Прочитал статью. Очень элегантный переход. Единственное, что меня смущает в больцмановских мозгах - мы не знаем что такое сознание. Можно сказать, что это всё философия, но раз уж мы привлекаем нашу субъективную реальность (наблюдение) для описания, странно было бы игнорировать природу сознания. И здесь всё зависит от подхода в философии сознания. Если мы берём за основу физикализм и редукционизм, то да, мы можем считать, что больцмановский мозг имеет сознание, в функционализме сознание может требовать устойчивых причинно-следственных связей с окружающим миром, которых у больцмановского мозга нет, а в дуализме больцмановский мозг будет являться философским зомби, то есть мы не сможем им оказаться. Но вообще статья выглядит очень убедительно.
Ну да. Плохой архиватор даст высокую сложность даже для простых данных, а идеальный теоретически может сжать любое состояние до "шаг N в системе S". Но идеальный архиватор же переносит сложность в себя. Чем специфичнее закономерности, которые он умеет распознавать, тем сложнее сам архиватор. Его собственная сложность будет приближаться к сложности описываемых процессов, мы просто переносим сложность в архиватор, а не избавляемся от неё. Плюс даже зная точные формулы, обычно нельзя перескочить вычисления, каждый шаг нужно выполнить. Для хаотических систем вообще нет короткого пути - состояние через N шагов можно получить только последовательно. То есть опять же, либо мы переносим сложность в архиватор, либо рассматриваем какие-то очень специфичные случаи, которые могут быть применены к отдельным сценариям клеточных автоматов, но вряд ли - к эволюции Вселенной.
и сюда же ещё эту статью скину, чуток упоминал её в предыдущем комментарии, но явно дополню со ссылкой. Здесь Вольфрам утверждает, что второй закон – это следствие вычислительной сложности: т.е. поскольку мы (ограниченные наблюдатели) не можем эффективно вычислить детальное поведение системы изнутри, нам оно выглядит случайным, и мы вводим энтропию как меру этой случайности. И хотя можно сконструировать вычислительные системы, демонстрирующие явное различие между микроскопическим описанием и генерирующим алгоритмом, в физических системах таких “подобранных” случаев практически не встретишь, а если и встретишь, они крайне маловероятны. Поэтому при изначально вычислительной природе Вселенной, второй закон в целом применительно к космологии работает хорошо, тем более, что у нас уже есть проверенные методы расчёта энтропии для физических систем, в отличие от более абстрактной меры вычислительной сложности.
А почему вы считаете, что я не отвечу? Ваше сравнение разбиралось и Стивеном Вольфрамом и например вот в этой сравнительно недавней статье. Да, из статьи может сложиться впечатление, что я чуть ли не уравниваю термодинамическую энтропию с колмогоровской сложностью, т.е. фактически термодинамическая энтропия = K(x). Но связь между этими величинами не настолько прямая.
В той же статье по алгоритмической термодинамике предлагается формула для алгоритмической энтропии состояния:
которая разделяет вклады логарифма меры и колмогоровской сложности. т.е., алгоритмическая энтропия учитывает не только сам алгоритм, порождающий состояние, но и статистическое множество микросостояний, к которому оно относится.
Представьте, что термодинамическая энтропия – это такая мера, которая зависит от того, как мы группируем все мельчайшие детали. То есть, она в какой-то мере субъективна - всё зависит от того, что именно мы считаем важным, а что можно упустить. А алгоритмическая сложность, по сути, показывает, насколько коротким может быть «рецепт» для создания конкретного состояния системы - и это более объективная характеристика.
Например, если у вас есть клеточный автомат, который генерирует узор, то, если вы знаете правило, начальное условие и номер шага, формально описание этого узора может быть очень компактным. То есть, по колмогоровской сложности оно простое. Но без знания этого правила узор для нас выглядит случайным и сложным - т.е. термодинамическая энтропия.
Стивен Вольфрам указывает на эту разницу: он говорит, что тут важно различать то, что мы видим (наблюдаемая случайность, которая отражается в статистической энтропии), и то, что на самом деле лежит в основе (простой алгоритм). Конечно, можно теоретически придумать вычислительные системы, которые «обращают» процесс и нарушают привычное направление второго закона, но в реальной физике такие случаи практически не встречаются - они слишком маловероятны.
Таким образом, разночтения между алгоритмической сложностью и термодинамической энтропией вовсе не опровергают идею, а скорее подчёркивают, что второй закон – это, в конечном счёте, статистическое правило для типичных систем. То есть, даже если формально узор может быть описан коротко, для нас он выглядит случайным, потому что мы не знаем сжатого описания. И возможно алгоритмическая энтропия может быть более фундаментальной, так как дает глубже представление о сложности системы Т.е. мне не кажется, что основная идея, возможность описания эволюции Вселенной как вычисления, описываемого в том числе алгоритмическим подходом к термодинамике здесь страдает. Но опять же, я не подаю эту идею как однозначную истину, однако если оно будет работать - последствия этого мне кажутся очень интересными.
в принципе, лечится языковыми реформами. Чем позже она была - тем ближе написание к произношению. Но если давно не проводить - да, придётся отдельно запоминать письменную форму слов, что недалеко от иероглифов.
Claude:
В танцевальной мини-игре в клубе в GTA San Andreas представлены следующие треки:
"Running Away" от Roy Ayers
"Rock Creek Park" от The Blackbyrds
"Hot Pants" от Bobby Byrd
"Hollywood Swinging" от Kool & the Gang
"Love Rollercoaster" от Ohio Players
"Express Yourself" от Charles Wright & the Watts 103rd Street Rhythm Band
o3-mini:
В GTA San Andreas существует специальная миниигра – танцевальный конкурс в ночном клубе, где во время танца играют заранее зафиксированные треки.
• Один из трёх музыкальных треков, сопровождающих танцевальную миниигру – это композиция Kool & the Gang «Hollywood Swinging». Именно этот трек звучит, например, на втором уровне конкурса, и именно он часто упоминается фанатами как классика для такого мероприятия.
• Кроме «Hollywood Swinging» существуют ещё два трека, которые можно разблокировать по мере набора очков в миниигре. После успешного прохождения первого или второго этапа игрок получает возможность сыграть следующий трек – его часто называют «Funky» или дающим более зажигательный фанк, хотя точное название второго (и, возможно, третьего) трека может варьироваться в зависимости от версии игры и локализации.
Не в контексте, поэтому не могу оценить уровень галлюцинаций.
возможно для каких-то более специализированных вещей так и есть, но с веб-разработкой современные модели справляются очень хорошо. 50-60% случаев с косяками давно не наблюдаю, а если косяки и появляются довольно часто проблема в том, что я сам не точно сформулировал запрос.
Может быть и так. Сейчас очень сложно предположить каким именно будет рынок труда во время AGI. Один вариант - да, получится как с компьютеризацией, с помощью ИИ мы начнём открывать те области, которых пока нет (например, как появилась новая область по доставке продуктов или по обслуживанию IT-систем). Другой вариант - ИИ будет эффективно выполнять всю ту работу, что можно сейчас сделать условно на удалёнке, тогда этот труд или перетечёт во что-нибудь другое или нет. Но там полностью неизведанная территория, я не знаю как это прогнозировать.
А всё остальное - обычные навыки программирования, которые мы применяем на код ревью. Я к тому что дополнительного обучения совсем немного, а буст по скорости разработки уже значительный.
в краткосроке да. Задач всегда много, можно просто начать делать то, к чему раньше было не подступиться. Но мы только на самых ранних этапах, в дальнейшем традиционный кодинг может перейти во что-то совершенно другое.
это сильно менее квалифицированная работа, чем писать всё самому. Нейронки всё лучше и лучше понимают, что хочет пользователь. Это скорее сродни навыку "гуглить" и "смотреть stackoverflow", чем что-то, чему сложно обучиться.
Обычно такое лечится очень простыми промптами. Например, "давайте сперва продумаем оптимальную архитектуру, а потом напишем код", "напишем для окружения с такими-то версиями". Ну и писать все нюансы лучше заранее. В любом случае перед написанием кода и без LLM их надо будет продумать. Не обязательно как-то извращаться, максимально короткие фразы LLM отлично понимают. А про удаление частей кода - современные нейронки корёжат код всё реже и реже. Раньше это было проблемой, но не сейчас.
А зависимости от ChatGPT уже нет. Падает он не то что бы часто, так-то и прогер может заболеть. А если всё-таки упал - есть Claude, есть тот же DeepSeek на сторонних хостингах и т.д.
Не обязательно очень хорошо разбираться. Можно набросать прототип на не слишком знакомой тебе технологии. В прод код, который не понимаешь, конечно лучше не тащить, но чтобы проверить теорию, уже подходит отлично.
Понять когда LLM применимы, а когда пока ещё нет, довольно просто. Если я вижу задачу, которая проблемна для LLM, я просто делаю её сам, максимум делегирую нейронке бойлерплейт по ней. Было пара ситуаций, когда LLM предлагала изначально неверное решение, которое выглядело как верное, и чтобы понять что оно не сработает, уходило много времени. Но это скорее исключение, которое не перевешивало сэкономленное время на других задачах.
Кажется, что большинство комментаторов использовали какие-то старые версии LLM. За те два года, что я использую LLM в программировании я вижу очень большой прогресс. В GPT 3.5 даже на небольших задачах часто были галлюцинации. С o1/o3-mini-high, а иногда и с Claude 3.5 Sonnet я могу накинуть сразу несколько файлов для контекста, скопировать задачу из Jira и сказать "пиши". В большом проценте случаев ИИ напишет с первого раза как надо.
Да, LLM может что-то не учесть или использовать старую библиотеку, но это больше вопрос к промпту. Да, иногда было такое, что LLM с самого начала предлагала не самое оптимальное решение, и на его разбор мне приходилось тратить больше времени, чем если бы я написал сам. Но в основном нейросети мне в ежедневном режиме очень экономят время. Да, нужно ревьювить каждую строчку, но это в любом случае надо делать. А исправлять приходится всё меньше и меньше. Тут и нейросети вышли на новый уровень и я научился что, как и в каких случаях у них запрашивать.
Я не вижу причин, почему эта тенденция должна остановиться. Пока есть проблемы с большим контекстом и связкой с пользовательским опытом (LLM видит только код, но не интефейс продукта в динамике), но это не выглядит нерешаемым.
В краткосроке наверное ничего страшного не произойдёт. Программисты будут эффективнее, но задач много, можно будет просто начать делать те задачи, которые раньше не сходились по экономике, а теперь начнут сходиться.
Но в дальнейшем LLM вполне могут заменить не только джунов и мидлов, но и тимлидов, PM и т.д. Эта работа требует большей квалификации, происходит на более высоком уровне абстракции, но в целом такая же работа с данными, во что LLM умеют. Пока не так хорошо, как работать с атомарными задачами, но посмотрим что будет дальше.