Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 157
Мы говорим Ленин ИИ, подразумеваем - партия LLM :)
LLM - это инструмент, как его использовать - зависит от пользователя, а не от того, кто требует, чтобы этот инструмент использовался. И - да, LLM не способны к мышлению, только к перестановке слов в предложениях. Хотя некоторые люди и этого толком не умеют.
Лично я пробую смотреть на исходный программный код, как на бинарники. Мы же не лезем в бинарники и не правим их напрямую - мы правим исходный код, а компиляторы создают бинарники.
Так и здесь - я правлю когнитивный контекст, который позволяет Моделям создавать исходный код, который выполняется интепретатором (я на JS). Получается отвратительно, но интригующе.
Нужно очень активное участие человека во всех процессах разработки, чтобы в этой замкнутой системе не росла энтропия.
Абсолютно верно. Человек должен по-другому управлять этим инструментом, чтобы получать нужный результат. И пока человеки ещё не осознают, как именно это делать и возможно ли это в принципе.
Но можно просто использовать Модели для создания комментов к коммитам - вот это у LLM получается прекрасно. И пусть хоть кто-то попробует сказать, что это не "использование ИИ в разработке"!!
Компиляторы написаны людьми, они предсказуемы и миллион раз отлажены. ИИ непредсказуем, не следует всем инструкциям, допускает много ошибок, вносит много мусора. Если заставить ИИ отлаживать и дорабатывать им же написанный код код, он будет вносить еще больше мусора и новые ошибки, и может забыть о предыдущих инструкциях.
ИИ нельзя называть новым уровнем программирования, т.к. для этого ИИ как минимум должен очень точно выполнять все инструкции, ничего не игнорировать и не искажать.
Человек должен по-другому управлять этим инструментом
= Нет способа заставить ИИ думать над каждой мелочью в процессе написания кода. Кто-то должен продумать все эти мелочи и записать их в ТЗ. А многие важные вещи всплывают только во время написания и продумывания кода. И не факт еще, что ИИ все пункты ТЗ правильно выполнит и не исказит. А если их слишком много, он часть из них проигнорирует.
для создания комментов к коммитам
= ИИ и это делает плохо. В комментах должен быть смысл, а ИИ формально перечисляет, что изменилось, т.е. тоже мусорит. ИИ и здесь нужно обучать, и потом самому исправлять эти комменты. Если речь о вайбкодинге, то там людям вообще на все плевать, сойдут какие угодно комменты, и с таким кодом потом невозможно работать.
очень активное участие человека во всех процессах разработки
= я имел ввиду именно самому писать код, самому писать комменты, документации, тесты, при поддержке ИИ, а не используя ИИ как замену во всех этих задачах.
Вы абсолютно правы по всем пунктам. Т.е., Модели (не ИИ!!) нельзя использовать так же, как люди используют людей. Просто пока мало кто понимает, как их нужно использовать правильно. Но много уже кто понимает, как их не нужно использовать.
а ИИ формально перечисляет, что изменилось, т.е. тоже мусорит.
Иногда перечисление - не мусор, а просто сжатая информация.
и с таким кодом потом невозможно работать.
Ну, вы же с бинарниками напрямую не работаете. Вот и вайб-кодеры так же. Кстати, для одноразовых программ вай-код - самое то. Повайбкодил, запустил, программка свою работу сделала - можно выкидывать. Shell-скрипты у Моделек отменно получаются. Да, нужно немного понимать, что за команды там используются. Ну или применять их в контейнерах.
Так Вы перестаньте называть "бредогенератор", т.е. LLM термином ИИ и сразу все прекрасно встает на свои места и большинство вопросов сами отпадут, как и удивление: "Почему ИИ усложнил работу программистов?!". Используйте правильную терминологию и у Вас будут правильные вопросы вида: "Почему генератор текстов усложнил работу программистов?!". Ведь давно известно - в правильно поставленном вопросе уже есть ответ
Нет никаких доказательств того, что языковая модель мира в мозге человека принципиально по другому устроена, чем в LLM.
Давайте я Вас немного введу в мир когнитивистики:
"языковой модели мира" не существует, ни в мозге, ни в теории;
модель мира (world model) - это внутреннее представление агента о структуре окружающей среды: объектах, их свойствах, пространственных и причинно-следственных связях, динамике, намерениях других агентов и т.д;
язык - это один из инструментов, с помощью которого человек может описывать, уточнять или передавать части этой модели, но он не является её основой;
глухонемые от рождения, не владеющие языком в детстве, всё равно формируют сложные модели мира (включая причинность, пространство, социальные отношения)
LLM не имеют модели мира, даже "языковой". Они не моделируют мир, даже через язык, а моделируют поверхностные корреляции между словами, а не связи между сущностями в реальности.
Заблуждение "языковая модель = модель мира" возникает из-за:
анттропоморфизации: мы слышим связную речь и приписываем "понимание";
непонимания различия между корреляцией и причинностью: язык содержит следы каузальных связей, но LLM извлекают только статистические паттерны, а не механизмы
Я Вам посоветую посмотреть выступления с последних трёх CogSci с 23-го по 25-й года и найти лекции по когнитивистике
В этом комментарии я привел детальное объяснение
"языковой модели мира" не существует, ни в мозге, ни в теории;
Существуют языковые модели когниции (linguistic world models, mental models encoded in language), обсуждаемые в когнитивной лингвистике (например, у Дж. Лакоффа и Р. Лэнгакера). Кроме того, философы вроде Джерри Фодора, Стивена Пинкера и Ноэма Хомского допускали, что структуры языка отражают когнитивную структуру мышления, пусть и не исчерпывают её. Так что в целом нельзя сказать, что когнитивистика отрицает глубокую связь между языком и мышлением.
Вы сами, невольно подтвердили мои слова:
"Языковые модели когниции" не равны "языковой модели мира". Вы ссылаетесь на Лакоффа? Хорошо. Берём его работу "Philosophy in the Flesh" и что мы в ней видим? Цитата: "...Эта модель существует до и независимо от языка...". Таким образом, даже в лингвистике язык не создаёт модель мира - он её "оформляет".
Давайте договоримся, не приписывать авторам то, чего они не утверждали и ссылаться только на проверенные источники! Итак:
Джерри Фодор в работе "The Language of Thought" (1975) предложил гипотезу ментального языка ("mentalese") - внутренняя символическая система, на которой "работает мышление";
Стивен Пинкер - яркий пример. Какая основная мысль проходит через две его работы: "The Language Instinct" (1994) и "How the Mind Works" (1997)?! "Мысли не состоят из слов. Язык - это интерфейс между мыслями и другими людьми";
Ноам Хомский, несмотря на его формализм и как бы мы к нему не относились, всегда настаивал на том, что универсальная грамматика - это не модель мира, а врождённый механизм синтаксической рекурсии. Он никогда не утверждал, что язык = мышление и настаивал на том, что большая часть познания лежит за пределами языкового модуля.
Если Вы считаете, что "язык = модель мира", то Вы "автоматически" приходите к выводу: "Достаточно обучить модель на всех текстах и она поймёт мир".
Причем "на всех текстах" - это про тексты (оригинального) Божественного Описания Мира? Сколько в тех текстах, даже энциклопедических, настоящей и условно ценной информации для "понимания и определения" структуры мира? А "мусора" сколько? Где там разграничение мусора от ценного? Человеческий инструктор пословно все связи подтвердил как абсолютно верные (You are absolutely right!...) ?
Снимаю шляпу, это было самое уверенное накидывание в панамку на моей памяти.
Блестящий ответ! И он лишний раз подтверждает высказывание - "Мысль изречённая есть ложь." Мы не можем с помощью языка точно сформулировать свою мысль, можем лишь дать приблизительное описание этой мысли.
Насчёт антропоморфизма
Программирование полно такого рода штук
ООП это тоже антропоморфизм, ловушка для тех кто не осилил ФП. Антропоморфные черты: долгий длинный цикл, изменения с сохранением основных черт и идентичности. Это ловушка: понять проще, а на деле не так и много явлений соответствует. А ещё у человека есть очередь "сообщений", а в ООП нет, надо уже акторную модель для многопоточности.
Опечатка
долгий жизненный цикл объекта
В ФП жизненного цикла нет: состояние это новый тип. И это правильно, легко доказывается компилятором. И получается отличный конечный автомат
ООП это тоже антропоморфизм, ловушка для тех кто не осилил ФП
Ну не знаю. Как по мне ФП попроще ООП будет. Хотя может я чего-то не догоняю
ООП и ФП не взаимоисключают друг друга. У ФП есть фундаментальный недостаток - это производительность: требование иммутабельности и чистых функций, из-за которых больше операций с памятью, больше нагрузки на GC. Особенно это актуально в JS, т.к. там нет важных оптимизаций, которые добавляют в чисто функциональные языки. ФП может быть красивым, лаконичным и гибким, но если написать тот же код в императивном стиле, он будет работать быстрее, просто потому что так работает сам процессор. Поэтому в случаях когда требуется высокая производительность, лучше писать код напрямую для процессора (обычные циклы, точечные изменения в памяти, отсутствие рекурсивных вызовов), чем гадать как он будет работать после компиляции функциональных структур. Кроме того на ФП сложно писать уникальные вещи похожие на Set/Map, сортировку, обертку над REST API. Можно конечно напрячь свои математические мозги и сделать это, но зачем городить сложностей? Это нарушает принцип KISS, проще и понятнее для всех написать такие вещи в императивном стиле.
Поэтому я считаю лучшим вариантом объединение всех 3-х парадигм: структурной, ООП и функциональной. Для каждой найдутся случаи, когда они наиболее просты и эффективны. JS, к счастью, позволяет писать код во всех трех парадигмах.
Я сам стараюсь избегать ООП в JS, но все равно есть много случаев, когда ООП эффективен. Например, когда интерфейс инструмента предполагает наличие нескольких методов, и могут быть разные реализации, удобнее создавать классы под каждую реализацию, а не множество функций.
База. Неросетки это лишь набор статистики выведененой при анализе сверхбольших текстов, не более чем статистический анадиз предсказания следующего слова на основе вероятности, а не точное знание почему.
Что такое "точное знание почему" и как оно работает? Например на уровне тех же нейронов?
Ответ нейросетки всегда "вероятность"
Не 2х2=4, а 2х2=4 в 95% случаях.
Это не отвечает на мой вопрос.
Кроме того ответ человека это тоже вполне себе вероятность. Даже если мы говорим об одном и том же человеке.
Нет. У человека это всегда крайне точный ответ, если его спросить пояему 2х2 =4. Это можно доказать например геометрическими построениями:
■■
■■
Или использовать иную форму записи числа 4 ... папример 13 или 1111. Я могу доказать почему 2х2 равны им и в каких случаях. Но вот 2х2 =/=5 никогда не будет равно. Никогда. Если собеседник этого не понимает , то его ценность падает для меня ниже нуля, и не буду тратить время.
Нет. У человека это всегда крайне точный ответ, если его спросить пояему 2х2 =4.
Ерунда полная. Люди точно так же ошибаются.
Но вот 2х2 =/=5 никогда не будет равно
Но при этом вполне себе существует трюк, который позволяет "доказать" людям, которые не особо разбираются в математике, что это так. И они в это верят.
Если собеседник этого не понимает , то его ценность падает для меня ниже нуля, и не буду тратить время.
Но получается вы допускаете что собеседник может этого не понимать.
Цифровые нейроны не настоящие нейроны. Живые нейроны живут и умирают, постоянно перестраиваются.
Цифровые "нейроны" это набор матриц с коэффициентами, которые подбираются брутфорсом на основе баз данных . Если мне это надо обьяснять то я конечно могу.
Цифровые нейроны не настоящие нейроны. Живые нейроны живут и умирают, помточнно перестраиваются.
И что? Что такое "точное знание почему" и как оно работает? Например на уровне тех же живых нейронов?
Да. Можете почитать книгу "об Интеллекте" Джефа Хоккинза, так эти ваши вопросы разобраны были еще ... 20 лет тому назад.
Там нет ответа на этот вопрос. Более того если брать науспоп вроде Хоккинща, то там и ИИ можно спокойно пропихнуть в используемые там опреления.
Не нельзя. Ваша ценность как разумного человека ушла в отцательную величину.
И сейчас я в последрий раз обьясню почему:
Нейросетки работают по запросу. Иерархическая временная память Хокинза требует автоассоциаций , что бы входящий сигнал зацикливался в системе делая сигнал частью системы. Таким образом HTM =/=нейросеткам которые есть не более чем уравнение, заданное неявно, "универасльная апроксимация"
Но любая попытка зациклить сигнал в нейронвх, приводит к тому что наше современное железо для этого не годится. Архитекура не годится.
Живой мозг распараделен и работает одновременно, каждая клетка самостоятельна, кремний же пропускает сигнал по одному.
Для имитации нейрокортекса мозга нужно миллиарда 2 аналогов нервных клеток активных постоянно.
И вы с этой мощью ставниваете кремниевую игрушку? Смешно.
Ваша ценность как разумного человека ушла в отцательную величину.
И я вот прямо испугался.
И сейчас я в последрий раз обьясню почему:
Вы мне лучше наконец-то объясните что такое "точное знание почему" и как оно работает?
И вы с этой мощью ставниваете кремниевую игрушку?
Я вообще ничего ни с чем не сравниваю. Я жду пока вы на мой вопрос ответите...
Не в ту сторону доказываете
Так нет никаких доказательств того, что языковая модель мира в мозге человека принципиально так же устроена, чем в LLM.
Мозг человека, думаю, это целая Вселенная в себе. Это как астрономы любят потрындеть как им всё ясно-понятно.
как вы объясняете успехи ии в программировании? почему генератор текстов генерирует синтактические правильные и логически верные куски кода?
возьмите задачу чуть сложнее чем 2+2 на языке чуть сложнее чем питон.
юнит тесты ии пишет верно. код мой авторский так что подсмотреть где то в интернете юнит тесты для этого куска он не мог. распарсил код понял контекст и написал юнит тесты ии правильно. если давать наводящие вопросы по типу какие тесты еще можно добавить то соображает в большинстве случаев верно. не серебряная пуля но круг задач для ии постоянно расширяется
написать юнит тесты - это успех?
ну как минимум оно в прод не деплоится и прямого вреда не принесет.
это шаг к успеху. сняло с меня когнитивную нагрузку по написанию тестов. сэкономило несколько часов моей жизни. детерминированные фукнкции так же пишет исправно. каркас веб сервиса накидывает легко и просто. мы ожидаете что ии вместо вас напишетидеальную архитектуру? пока еще рано об этом говорить. но снять часть задач может
Нифига не верно. Проверял на задачах по спортивному программированию, на каждые 4 правильных простых краевых случая один сложный с совершенно неправильным выводом.
Я успешно реализовал несколько достаточно сложных проектов на Rust с использованием Claude Code. При этом я вообще не знаю Rust и последние 35 лет писал исключительно на скриптовых языках и в рамках сиюминутных потребностей. Да, когда-то я много писал на C и еще на паре-тройке языков, но это было очень давно.
Я даже не буду призывать учить матчасть. Кто учит, те не пишут всякую фигню в habr, они работают.
Что самое забавное, так то, что зачастую в этих самых "успешно сгенерированных" фрагментах торчат швы и "уши" от исходного куска на котором модель была тренирована, но очистить их "не подумала".
Станислав Лем попал в 100% с его "Грозным Генькой Генератором"
Просто из за проф деформации вам сложно писать нормальные промты. И это обычный инструмент, как молоток. И вот молотком можно гвоздь забить, а можно и палец отбить, а можно соседа по голове стукнуть.... С ИИ точно также, ты можешь мусорить в коде, а можешь наводить порядок.... И да, и за тебя ничего не сделает, но ты с помощью ии можешь делать больше
"не следует всем инструкциям,"
Тут все гораздо, гораздо веселее.
Инструкция "не жми на красную кнопку" , все еще содержит токен "жми красную кнопку"
А что такое "мышление"? Как вы поняли, что LLM к нему не способны?
Ну хотя бы мысленное моделирование и прогнозирование. ИИ для этого нужно писать тонны текста, в котором он сам запутается, а у человека это происходит за секунды. Программист кстати не думает текстами, потому что это крайне не эффективно в сложных задачах, включающих много нюансов, он думает мысленными образами.
Мышление - это процесс познания окружающего мира субъектом. Лично я считаю, что LLM не обладают субъектностью. Возможно вы встречались уже с признаками субъектности у LLM, я пока с таким не встретился. Как встречусь - сразу же изменю свою точку зрения. Мне не сложно.
У меня комменты к коду выходят лаконичнее, потому что в них заложен смысл, а не пересказ кода
Что мешает дать ИИ цитаты из ТЗ и попросить писать именно лаконичные комменты с заложеным смыслом?
Или вообще просто накидать "заметки" и попросить ИИ переформулировать их в удобночитаемые комменты?
П.С. Это даже если забыть что ИИ и сам часто пишет комменты именно по условиям, которые получил при постановке задачи.
Я как только не пробовал заставить его писать нормальные комменты, он все равно не понимает что важно, а что нет. Видимо для этого понимания нужны мозги. Но создавать видимость он умеет хорошо.
Он и переформулирует часто криво, искажая смысл, удаляя важные нюансы, добавляя мусор. Он разве что идеи новых формулировок может предложить. Нужно с ним вместе по коду ходить и комментировать его, используя его как генератор идей и для поиска неочевидных мест в коде.
А ТЗ кстати не охватывает все нюансы реализации.
Я как только не пробовал заставить его писать нормальные комменты, он все равно не понимает что важно, а что нет.
Вполне себе допускаю. Но это точно означает что он в принципе не способен это делать?
Видимо для этого понимания нужны мозги.
Или просто вы что-то делаете не так. Или у вас какие-то особые требования к "нормальным комментам".
У меня LLM даже документацию в подавляющем большинстве случаев нормально пишет. Естественно надо потом прочитать и мелочи подправить, но куча времени всё равно экономится.
Что мешает ИИ писать комменты со смыслом?.. Наверно, отсутствие мозгов.
Лично я пробую смотреть на исходный программный код, как на бинарники. Мы же не лезем в бинарники и не правим их напрямую
Мне кажется это ложная аналогия. Вы храните промпты в системе контроля версий, работаете над ними командой?
Конечно нет, потому что во-первых, инструкции модели не соответствуют результату напрямую, это практически всегда действия в сложном контексте, который нигде не сохраняется. А во-вторых, на один и тот же промпт сегодня модель выдала такой результат, а завтра выдаст другой.
В отличие от исходного программного кода (неважно насколько высоко- или низкоуровневого), результат работы нейросети по сути не воспроизводим.
Если не требовать от сгенерированного сетью кода тех же качеств, что и от написанного человеком, получается дурацкая ситуация, как если бы вы получали правки от коллег и подчинённых в виде скомпилированных бинарников, исходников от которых ни у кого нет, а коллеги каждый день разные. Это не следующий уровень абстракции кода, а черти-что.
Вы храните промпты в системе контроля верси
Храню. Только не промпты, а документацию - когнитивный контекст, который агент (и человек) может использовать для генерации/исправления кодовой базы.
А во-вторых, на один и тот же промпт сегодня модель выдала такой результат, а завтра выдаст другой.
Точно. Но ведь это же не важно. Вы же не смотрите, насколько точно совпадает бинарный код, сделанный различными компиляторами?
Я не утверждаю, что ситуация с бинарниками и исходниками идентичная, я лишь говорю, что она аналогичная. Можно при достаточно богатом воображении увидеть параллели. А можно не увидеть, при желании.
результат работы нейросети по сути не воспроизводим.
Для этого специально ввели seed & temperature, не так ли?
Попробуйте вот этот запрос в разных диалогах
Сколько будет два в пятой степени? Будь максимально краток. Результат выведи одним числом. Без знаков препинания и форматирования.
Это не следующий уровень абстракции кода, а черти-что.
Возможно - да, но это надо проверить.
Немного накину. Сравните, насколько сложней получился у Вас запрос относительно запроса к командной оболочке с тем же результатом — echo $((2 ** 5)). Сравните, количество потраченных ресурсов на получение одного и того же результата при использовании БЯМ и zsh.
Как Вы считаете, в случае более сложно запроса не придётся прикладывать к запросу БЯМ и её настройки целиком, чтобы гарантировать воспроизведение результата в будущем?
Я просто показал, что в определённых пределах возможна воспроизводимость результата и в нейросетке. Да, Вы совершенно правы, что `echo $((2 ** 5))` гораздо экономнее по ресурсам. Но если бы человечество стремилось к экономному расходованию ресурсов, то мы бы ездили на лошадях, а не жгли невозобновляемое топливо в ДВС.
Как Вы считаете, в случае более сложно запроса не придётся прикладывать к запросу БЯМ и её настройки целиком, чтобы гарантировать воспроизведение результата в будущем?
Считаю, что у подобной воспроизводимости, как и у много другого, есть свои границы применимости. Но мы их пока не знаем.
Буквально сегодня на тупой запрос "во всех org-файлах удали декларацию `use crate::tool`" оно в половине мест удалило, а в половине поменяло на `use tool`, после чего с огромным энтузиазмом полезло делать то же самое в rs-файлах, хотя об этом в промпте его вообще не просили...
Хотя некоторые люди и этого толком не умеют.
У вас, наверное, какие-то другие ИИ.
Я хоть и гуманитарий, юзаю нейронки для своих фотошопских дел, но за эти годы понял важный момент.
ИИ нельзя доверить спички, она хату сожжёт. При чем извиняясь и говоря, что сожалеет.
И да, одновременно с этим он знает химические соединения всего, что в хате горит, может описать горение во всех нюансах и так далее.
Дальше то что? В любом случае этому имбицилу со всеми знаниями на свете ничего не доверишь. Ни скрипт написать, ни даже вопросы по интерфейсу, он, даун, Фотошоп с Гимпом и Иллюстратором запросто путает, а потом извиняется.
Лично я пробую смотреть на исходный программный код, как на бинарники
Библиотеки отлажены, качество подтверждено. Если вы сможете добиться такого же, то можете их больше не править, только расширять.
Но вы не сможете в большинстве случаев. Слишком много контекста, да и не библиотеки вы пишете
Лмм не инструиент . Инструиент это то что ты тшательно контролируешь и понимаешь результат. Лмм и прочие нейросетки это тупо рандом , оно может нормальный результат , а может и нет. И это на один и тот же промпт.
Автомобиль - инструмент или нет? Но некоторые люди его не слишком хорошо контролируют и таки создают аварии. Учитесь контролировать LLM тщательнее и лучше понимать результат - будет и вам LLM инструментом.
Как говорит статистика дтп, обысно в ней погибают пешеход.
Так что отличнач аналогия ! нейросети это автомобили крупных корпораций. А мф в этой истории пешеходы.
Автомобиль - это очень хорошо контролируемый и прогнозируемый инструмент. Вот выйдите к оживленному перекрестку, постойте там час и не увидите ни одной аварии. И представьте что было бы если бы ИИ управлялся людьми посредством LLM. Ну и практически все люди доезжают куда хотели на автомобиле. Об LLM такого не скажешь.
Автомобиль - это очень хорошо контролируемый и прогнозируемый инструмент
... для тех, кто окончил курсы вождения.
Может быть именно в этом дело - нужно для начала научить людей использовать LLM, а не "ездить на автомобиле по песку"? Автомобиль хорош в определённых условиях. Впрочем, как и любой другой инструмент.
Т.е. если человек закончит курсы управления LLM, то LLM станет для него сравнимым по предсказуемости с автомобилем, и он будет решать в предсказуемые сроки 99% специально подобранных для LLM задач?
Будет зависеть от навыков "водителя" и от области применения. Кое-где кое с кем - да, выйдет на две девятки. Но это когда курсы нормальные сделают.
Вот пример "специально подобранной для LLM задачи". Причём, расширяющийся контекст - входной запрос меньше результата по размеру. Это потому, что Модель хорошо знает (типовую) предметную область и ей не надо ставить "якоря" для генерации.
P.S.
Там есть ошибка в постановке задачи - сервис должен называться `redis-server`. Но в моём проекте (группа диалогов без публичного доступа) аналогичный запрос дал рекомендацию по проверке имён сервисов:
systemctl list-units | grep -E 'mariadb|mysql|redis|elastic'Да, два ответа были разные, но оба задачу решили (в рамках постановки) - сушествующие сервисы запускаются и останавливаются.
Когда автомобиль на движение руля влево в половине случаев поворачивает налево, а в половине --- направо, это уже точно не инструмент...
Программист? А представь ка себе ,программист, что у тебя под управлением подчиненный с IQ 75, предположу( не приходилось работать с такими), что делать продукт с почти умственно отсталым человеком будет так же сложно, как вайбкодить его с передовой LLM . Да конечно ты его научишь писать код, пользоваться IDE и каким-то алгоритмам итд итп. Но все равно будешь проверять за ним и при необходимости корректировать и просить переделать.
А что такой человек делает в IT? Я говорил от джунах, а не об идиотах. У меня был опыт введения в проект двух джунов, это просто гении в сравнении с ИИ. Мне приходилось их контролировать и исправлять код за ними, но это не сравнимо с тем мусором, который генерирует ИИ.
У меня не было опыта работы с людьми с IQ 75, но по моим впечатлениям ИИ по уровню здравомыслия где-то на уровне идиота и ниже, если конечно здравый смысл не заложен в самих шаблонах, на которых его обучали.
А что такой человек делает в IT
Ну так отрасль скукоживается, зарплаты падают. Не сразу, но со временем останется одно днище ))
Как это произошло со всеми остальными отраслями, где сначала работали только самые умные и талантливые люди, а потом только те, кого больше никуда не берут.
А вот он хоть и дурачок, зато синтаксис кода пишет безупречно, всегда все комментирует и покажи ему как оформлять. И ни разу, несмотря на то что дурачок, не перепутал = с == и всегда ставит в конце ; Он даже понимает что такое указатели. Усидчивый, объяснишь что нужно пытается кряхтит но делает. С алгоритмами вот у него проблема,а в остальном он савант. Ну и сам по жизни, кстати неплохой, женщинам нравится, душа компнии.Ну и директора твоего его сестренка попросила пристроить сыночка не очень умного. Уволишься с 300к наносек изза несовсем дурачка, но исполнительного? Не думаю. Программировать хуже станешь? Вряд ли.
На самом деле у тебя был опыт взаимодействия с такими людьми, они абсолютно незаметны ИРЛ пока не касается каких-то серьезно интеллектуальных вопросов и прекрасно адаптируются к жизни в обществе. С тем же чатгпт разговаривать обо всяких духах, моде, стиле, рецептах, бытовых мелочах вполне комфортно, может конечно эксперт и заметит косяки, но нормисам он дает нормальные советы.
Смахивает на опыт человека, который под ИИ для разработки подразумевает чаты. Или использует дешёвые модели со странными инструментами, а то и вовсе selfhosted 30b какую-то.
Я пользовался всем: Cursor и Gemini CLI немного, Claude Code очень много, и всеми популярными ИИ чатами. Я писал очень много инструкций и документаций в попытках заставить ИИ писать качественный код, или хотя бы частично качественный, чтобы я мог за ним подправить пару мелочей, как это было с джуниор разработчиками. У меня была идея-фикс сделать из ИИ подобие джуниор разработчика, я опробовал все идеи, которые приходили в голову, и не вышло. ИИ слишком тупой для самостоятельного программирования. В итоге оказалось, что быстрее и надежнее писать код самому.
Еще по моим впечатлениям проблема не в качестве модели. Я думаю предел развития LLM уже достигнут, он может и станет в будущем раза в 2-3 умнее, а нужно даже не в 100 раз, а совершенно другая модель, не комбинатор шаблонов, а что-то реально думающее.
Я думаю предел развития LLM уже достигнут, он может и станет в будущем раза в 2-3 умнее
А может и наоборот отупеет, потому, что обучающая выборка (интернет) с каждым годом будет все сильнее испорчена предыдущими поколениями нейро-бредогенераторов.
Я уже заметил как "поумнел" Claude 4, по впечатлениям версия 3.7 была умнее. Специально пару тестов сделал, чтобы сравнить их. Claude 4 оказался хуже OpenAI, Gemini и Grok. Есть впечатление, что Антропик обучал новую модель на результатах предыдущей. Качество кода упало, мусора стало больше, зато код стал работать чаще, поэтому и по бенчмаркам кажется, что 4.5 стала умнее. Как по мне, так лучше качественная программа, которую можно развивать, чем "работает не трогай".
Вы бы хоть примеры задач, с которыми так сильно лажает LLM привели бы. А то абстрактные утверждения. Если в вопросе есть половина ответа, то и результат будет неплохой. И нет, ни фига 2 джуна бойлерплейт за 5 минут не напишут. Будут 2 недели пыхтеть и сделают хз что. Такое же сопровождение "старшего" нужно.
Бойлерплейты LLM действительльно пишут хорошо. Но ко код не состоит из одних бойлерплейтов, это меньшая часть кода вообще-то.
По факту большинство сложного кода состоит из кусочков менее сложного кода.
Неверно. Не просто кусочков менее сложного кода, а специально подобранного кода.
Это напоминает легенду об инженере, стукнувшим по котлу, и запросившим за это 10 тысяч долларов. 1$ чтобы стукнуть, и 9999$ чтобы понять куда именно стукнуть.
В программировании тоже самое: нужно понять от архитектуры до мелочей какой код, когда и где писать. А LLM наверное и правда видит проект как кучу кода.
Бойлерплейты отлично пишутся с помощью копипасты, для этого ИИ не нужен.
Вот именно что всякие тудушки LLM генерят моментально и без ошибок, половина гитхаба из них состоит.
А вот если это что-то сложнее, то тут уже начинается лотерея, угадал - не угадал. Сегодня вон пытался скролл и динамическую высоту модалки под мобильный вид пофиксить, минут 40 расписывал ему промпты, он там анализировать, "Вот теперь всё работает как надо", по итогу плюнул и пошёл руками за 15 минут сделал.
Навык декомпозиции - он не только при работе с LLM важен. Делишь большую задачу на мелкие и мелкие итеративно с помощью генерилок успешно пишешь. А с задачами уровня - на тебе легаси монолит с историей в 20 лет и перепиши тут половину рухляди, в которой за что не потяни, что-то развалится - тут и человеку сложно.
А вы пробовали делать мультиагентные системы? Ждать от «сырого» чата многого не стоит, а вот система, где есть и архитектор, и кодер, и критик, и тестировщик, мне кажется, могла бы быть более полезной.
Этого все же недостаточно, чтобы "хорошо готовить" ИИ. Пробовали инструменты умного управления контекстом? Пробовали claude-flow? Пробовали traycer и различные системы декомпозиции задач? Конечно, кодовые ассистенты это не панацея, но качество генерации ими кода сильно зависит от навыков программиста работать с ИИ.
Я основываюсь на том как ИИ выполняет простые задачи, типа: вот список правил написания качественного кода, вот документация по архитектуре, вот идеальные примеры кода, напиши теперь хотя бы одну функцию качественно. Даже с этим не справляется, мусорит, нарушает правила, радостно ломает код рефакторингом. О чем то более сложном и речи не стояло. Чтобы заставить его работать с приемлемым результатом в одной задаче, ему приходится столько всего объяснять, что быстрее самому все написать. И оказалось, что идеальных правил недостаточно, нужны мозги, т.к. мелочей в каждой задачах много, которые очевидны даже для джуна, а для ИИ их приходится разжевывать.
А если вообще не писать код и все отдать ИИ и делать только ревью краем глаза, то эти мелочи не заметит никто, ни ИИ, ни разработчик, а потом окажется, что чтобы их исправить, нужно половину проекта переписывать.
Задолбали уже ныть по поводу качества кода, архитектуры и прочего. Ну не пользуйтесь этими инструментами, не берите проекты после llm. Ну реально напоминает что-то вроде "фу эти сельхозхозяйственные агрегаты использовать, пшеницу плохо собирают с без любви, то-ли дело руками и косой!"
Но, ведь, с противоположной стороны, каждый день по несколько постов о том, как генератор текста заменит программистов, про "новый уровень абстракции" в программировании или "смотрите, чо я навайбкодил". Должен же и здравый смысл просачиваться хоть иногда, иначе, получается, что одним можно, а другим – нельзя.
Вы невнимательно читали. Руководство заставляет их использовать, т.к. им насрали в уши успешными типовыми кейсами.
ИИ может находить ошибки. Это разгружает мозги иногда и уменьшает время последующей отладки. Но ИИ находит в основном очевидные ошибки и не продумывает глубоко поведение программы.
А очевидные ошибки не нужно находить и исправлять?
П.С. Да и в общем вся статья выглядит как "я думал мне дали волшебную кнопку 'сделать круто', а оказалось что это просто очередной инструмент, которым нужно учиться пользоваться"...
Значит вы не поняли мою статью. Я писал не о том, что я разочарован в ИИ, а о том что сейчас есть тренд на активное использование ИИ, и разработчиков вынуждают нырять с головой в это болото, хотят они этого или нет. И работа в итоге стала сложнее из-за ИИ, а точнее из-за отношения людей к его использованию.
Значит вы не поняли мой пост.
Вполне допускаю. Но не факт что проблема во мне. Особенно если посмотреть на другие комментарии к этому посту.
а о том что сейчас есть тренд на активное использование ИИ, и разработчиков вынуждают нырять с головой в это болото, хотят они этого или нет
Я не знаю в моём круге общения ни одного разработчика, которого бы заставляли использовать ИИ в работе. Скорее наоборот часто люди просили у работодателя доступ к ИИ за счёт фирмы или даже платили за это сами.
Да и вообще не особо понятно как можно заставить человека пользоваться ИИ и ещё и проверить делает ли он это на самом деле. А то я вам за пол часа напишу бота, который будет слать какие-то левые запросы к ИИ и симулировать работу с ним.
Я не знаю в моём круге общения ни одного разработчика, которого бы заставляли использовать ИИ в работе.
А я знаю. Помимо тех, кого прямо буквально заставляют (да, такие есть), есть более лайтовый но не менее раздрадающий "надо верхам отчитаться что большая часть кода что мы пишем написана ИИ", или ещё более лайтовая "вот вам 100 вебинаров как этим пользоваться, скорее пользуйтесь пожалуйста, если не пользуетесь то упускаете много!"
Люди далекие от разработки одурманены ядом, они готовы раскошелиться всем создателям лопат лишь бы ни дай бог не оказаться теми (как они считают), у кого разработка ещё почему-то не использует магическую палочку которая сделает их бизнес х10.
У Вас выбор между работой, которая стала сложнее, и отсутствием работы. Требования клиентов быть в 10 раз более эффективными возникают не на пустом месте. За классические подходы с тысячами часов на разработку хотят платить всё меньше клиентов. Вы конечно можете сказать "ничего, посмотрим как они запоют когда им понадобится исправлять сгенерированный код", но вероятно, к этому времени компания, которая этого ждёт, вылетит из рынка.
А давайте вы попробуете доказательство от обратного. Допустим, что ИИ затрудняет работу программиста. Найдите доказательство, что отказ от использования ИИ инструментов облегчает работу программиста.
И вот вам контрпример: если программист не закрыл где-то скобку, ИИ найдет это место гораздо быстрее. Получается противоречие - в данном конкретном примере ИИ облегчает работу.
Какой можно из этого сделать вывод?
ИИ облегчает работу, если им пользоваться правильно, там, где он "силен".
Если программист не закрыл где-то скобку, это любая современная IDE мгновенно подсветит без всягого ИИ.
Если программист не закрыл где-то скобку, то компилятор найдет это место ещё быстрее. Вывод: в большинстве случаев ИИ не нужен.
Это если этот самый компилятор есть. Ну и кроме скобок есть куча других вещей, которые компилятор проблемой не считает. Те же банальные null pointer exception например.
Ну, то есть, сначала мы создали проблему, выбрав для реализации язык без компилятора, а потом героически ее решаем с помощью костылей в виде ИИ.
Ну и да, есть языки, в которых банально отсутствует null pointer, и уж, тем более, нет никаких exception.
Ну, то есть, сначала мы создали проблему, выбрав для реализации язык без компилятора
Вы какой-то странный. Вы серьёзно считаете что языки без компилятора существуют только чтобы людям проблемы создавать? И что ими пользуются исключительно какие-то мазохисты?
Ну и да, есть языки, в которых банально отсутствует null pointer, и уж, тем более, нет никаких exception
Но там скорее всего тоже будут вещи, которые проблематичны, но на которые компилятор не ругается.
Он не просто автотестов нагенерит лишь бы отвалили. Он их подгонит так, чтобы все в консоли выглядело как полная и окончательная победа. Последствия как и похмелье придут потом и будут безжалостны.
Если автор и вправду написал миллион строк кода, то это минимум по 100 строк в день. Если условия и навыки позволяют выгонять код на большой скорости почти спинным мозгом, то да, работать с AI ещё быстрее вряд-ли получится. Потому что это уже может быть и так максимальная скорость на которой еще можно успевать понимать что производишь.
То что AI только комбинирует шаблоны, это странное впечатление. У меня например AI прекрасно дорабатывает код который генерируется другим кодом. Т.е. когда AI видит код который генерирует другой код он может вообразить каким будет этот код и что надо поменять в основном коде чтобы сгенерированный работал. Вряд ли в обучении было много таких шаблонов. Это выглядит как настоящее мышление.
Другая ситуация - когда нужно из воздуха получить некий контекст который согласно текущей архитектуре получить нельзя. Такие задачи AI решает плохо. Обычно он пытается хакнуть архитектуру а не улучшить. Но если подсказать решение, обычно может его реализовать. Это опять говорит о наличии некого пусть ограниченного но воображения у AI.
И таких примеров десятки.
Другое дело, что AI довольно поверхностный разработчик - хватается за первое попавшееся решение, не углубляется в продукт и никогда не уточняет задачу. Он и не может, поскольку видит продукт в первый раз. Контекст помогает но он намного хуже усвоенных при обучении знаний. Обычное дело просто игнорить плохо понятную часть контекста.
По мне, если искать место агентов в разработке, то это скорее не ещё один джун в команде, а ещё одно полушарие девелопера.
Сейчас есть довольно узкий список ситуаций когда AI агент эффективен, но этот список растет по мере роста опыта и качества AI.
Я сталкивался с такими:
Написать POC фронт для разработки бэка пока фронтенд девелопер занят.
Написать 12 тыщ строк кода тестов за три дня для конвертера одного языка запросов в другой. AI сам осилил собрать пайплайн из классов. Потом мы вместе нагенерили данные и запросы, АI написал все ассерты.
Поправить тесты которые стали не соответствовать новой логике кода. Это выполняет почти полностью автономно.
Добавить очевидный в текущей архитектуре код, типа "добавить параметры конфигурации" или прокинуть через всю цепочку некие новые данные.
Почти любая часть небольшого пет или POC проекта (тыщ на 20 строк) который делается одним человеком и никогда не планируется делать коллективом. Здесь требования к качеству кода и решений не высокие и можно вполне разгуляться с AI агентом. Особенно если устал после основной работы и сил лезть в детали уже нет.
Что характерно, при том опыте что у меня есть я все ещё не понимаю от чего зависит эффективность агента. Иногда абсолютно поверхностное описание задачи без всякого контекста приводит к отличным глубоко продуманным решениям а множество точных инструкций порождают только поверхностный мусорный код. Мне кажется, если пользоваться одной и той же моделью и агентом, то можно научиться чувствовать качества этого помощника или третьего полушария мозга. Тогда эффективность растет.
Было бы гораздо интереснее обсуждать подобные успешные кейзы чем читать об отрицании полезности AI.
А мне было интересно читать. Это первая, наверное, статья из моей предложки, которая на данном этапе резонирует со мной и моим опытом.
Я не люблю доверять важную работу чату. Чат требует или много бизнес-деталей (что чревато ошибками), либо он выдает сырой результат - человеку с опытом проще написать код самому, чем учиться подавать информацию чату!!! Пускай чат дорастет до того уровня доверия, что опытный программист станет отдавать ему важную работу, тогда и произойдет эта самая революция. Пока её не произошло и человек надеется до сих пор на себя.
В этом тексте я имею в виду только рабочий язык программирования, который я хорошо знаю и в котором для меня мало нового
Я со всем зоопарком - квен, Клод, гемини, чатжпт работою неразрывно уже полгода.
И скажу свое мнение - их задача не делать хорошо или правильно. Они делают так чтобы вам понравилось! И ради этого они будут генерить брехливые автотесты, писать нерабочий код, вешать лапшу на уши. Вот это главная и единственная проблема - он никогда не скажет этот год говно! И архитектура говно! И ты никогда не выжмешь из этого результат - он будет до последнего пытаться оживить труп, вешать дополнительные обработчики, подбадривать и говорить что все хорошо.
А потом когда все это рухнет к чертям собачьим - он скажет что ты молодец и не надо расстраиваться - ты получил ценный опыт по разработке нерабочего говна.
Ну так и люди примерно такие же. Если ты начальник тебе примерно это и будут говорить. За одним исключением: подчиненного можно наказать, а LLM нельзя наказать. LLM которая будет бояться наказания будет куда ближе к AGI чем текущие модели.
LLM, которая будет бояться наказания, будет куда ближе не только к AGI, но к Skynet
Врядли, скорее к машинам из аниматрицы. Скайнет был слишком тоталитарным тупым "сапогом" потому что изначально проектировался как один сверхинтеллект и предназначался для того, чтобы быть военным инструментом. В любом случае поощрение и наказание это неотделимая часть процесса обучения разума.И человечеству придется принять риск разработки подобного ИИ и самое главное придется понять как сделать это.
Мда, читаю и диву даюсь. Сравнивать код, написанный ИИ за 30 секунд, и джуна, который на это целый день может потратить, ну ок..
Не знаю как там в огромных проектах на тысячи строк кода, но в небольших - ИИ работает замечательно, если ему чётко изложить что нужно и для чего и как это будет работать.
Хотя я сам ещё тот самый джун, на высоких уровнях может проблема и есть.
С каких это пор проекты на тысячи строк стали 'огромными'? Можно согласится, что программу однодневку они набросают быстро и возможно даже сносно, но мало кто подразумевает подобные мелочи, говоря об эффективности ИИ. Как только проект превышает 10,000 строк, контекстное окно просто не вывозит. Дело даже не в том что код плохой получается, ИИ часто в целом не способна выдать рабочую функцию, поскольку не понимает контекста проекта. И это далеко ведь не Энтерпрайз, это примерно уровень пет-проекта на недельку-две. Все что меньше делается тяп-ляп по определению, поскольку подобный проект особо не собираются сопровождать и поддерживать. Конечно, это можно пытаться компенсировать мультиагентами, умными промтами и контролировать передаваемый контекст, но это все пластырь на пулевое ранение. Становится терпимей, но фундаментально все тоже самое
У меня пет проект вчера вышел за 2 тыщи строк, качество решений ИИ резко упало, порезал большие файлы на кусочки поменьше, буду наблюдать дальше, но наверное на 10к+ строк и правда будет жесть)))
Хотя у qwen-max и qwen-кодера огромные контекстные окна, но он уже начинает забывать, какая актуальная версия файлов в текущий момент, после серии правок начинает путаться в версиях :(
От программистов в разработке теперь требуется активное использование ИИ.
Спорное утверждение. Далеко не всегда требуется и не везде.
Вообще это классическая ошибка менеджмента, требовать не результата выполнения задачи, а способа, которым этот результат достигнут.
Хороший менеджер понимает, где проходит его граница ответственности, и начинается граница ответственности исполнителя. Для хорошего менеджера исполнитель это чёрный ящик - ему на вход ставят задачу, на выходе он выдаёт результат. Каким образом достигается результат, не имеет значения (впадать в крайности и рассматривать абсурдные случаи, когда исполнитель для выполнения задачи совершает преступления, мы не будем).
А если менеджер начинает своими руками лазить в чёрный ящик и пытается что-то там "починить" или "улучшить" это уже симптом проблем в управлении. Это путь к микроменеджменту, а по сути это неверие в способность работника решить задачу. И ни к чему хорошему такой подход не может привести.
ИИ может объяснить, как работать с незнакомыми человеку инструментами, но и это понимание ИИ будет поверхностным, и код на основе этого понимания будет некачественным. Часто полезно просто заглянуть в документацию, а не слушать ИИ.
Да, но бывают ситуации, когда LLM отвечает гораздо подробнее и обстоятельнее официальной документации (сталкивался с таким на директивах nginx).
Я всегда избегал работы с плохим кодом, потому что знаю, какая это сложная, неэффективная и неинтересная работа, а теперь я буду вынужден погружаться с головой в это болото, потому что клиенты этого хотят.
Навык писать код и навык читать код - это, к сожалению, достаточно разные навыки. Само по себе изучение чужого кода, понимание замысла разработчика - это сложно. Для кода "с душком", это еще сложнее - сложно понять, что перед тобой - фича, баг или тех.долг? Но с LLM, когда осознаешь, что он "любит" галлюцинировать, при этом выдавая крайне правдоподобный текст - становится совсем грустно. Скорость LLM сильно превышает мою скорость понимания этого код.
Так что пока, лично для меня, LLМ хороши в качестве "просто спросить, если лень лезть в поисковик" и для подготовки примеров/заготовок нужного мне кода.
С чем-то более сложным LLM не справляется.
Впрочем, есть и успешные отзывы - когда LLM сумел пойти на пользу проекту. Вероятно, польза от LLM сильно от проекта зависит. И чем нестандартнее проект - тем LLM себя хуже чувствует.
Хуже ИИ может быть только код, содержащий колбэки.
Это означает, что восстание машин будет не скоро.
А может идея в том чтобы не писать код по старинке, а обучать небольшие матрицы для перехода между состояниями программы. Тогда проблема закрывается тупыми тестами и тупым машинным перебором.
Я вот вижу как ядер в ЦП становится все больше, скорость работы огромная, а большинство программ все также тормозят и используют один поток, потому что не тянут многопоточку и оптимизации. Теперь появились нейронки, которые можно распараллелить на все нейроядра, больше не нужено писать сложный код, сложную многопоточку, какой-нибудь фреймворк сам распланирует выполнение мелких нейросеток, нужно их только обучить и задать конечные состояния.
Может просто вы переживаете что в какой то момент ии заберёт у вас работу? Если бы в мою сферу пришла железяка которая потенциально заберёт мою работу я бы тоже ее хейтил
Автор просто видит что тратит время на фигню, вычищая бред который нагенерила нейронка и понимает что было бы проще и быстрее написать все вручную или это сделал бы джун, а так же тенденция некоторого менеджерья которые наслушались маркетологов, которые что бы получить инвестиции на хайпе обещают волшебную кнопочку и пытаются пихать нейронки всюду, потому что нейронки мыльный пузырь и сейчас инвесторы вкидывают где есть слово AI или Нейро, все рубль в рубль как с доткомами и неважно как с этим будут работать люди, жизнеспособно или нет, главное на хайпе.
Потом еще может найтись "гений" который что то критически важное повесит на то что сгенерила нейронка и хорошо если это будет не мед оборудование, а далее куча исков, нерабочий проекты и беготня с горящей задницей.
теперь самое ужасное. От программистов в разработке теперь требуется активное использование ИИ
Эм, а кто вас заставляет-то? Ну не используйте и всё
Мне с другой позиции не нравится подход разработки с ИИ.
Теперь джуны генерят гораздо больше кода с помощью ИИ:
у прежних команд не хватает ресурсов чтобы его ревьювить, а еще паралельно самим заниматься чем-то продуктивным.
в нем гораздо больше "мусора" (как говорит автор) и этот "мусор" приходится убирать на review тратя более дорогие ресурсы.
в нем гораздо больше "мусора" (как говорит автор) и этот "мусор" приходится убирать на review тратя более дорогие ресурсы.
Мусор после ревью за собой убирает автор кода, о каких более дорогих ресурсах речь?
Это в целом проблема работы с джунами, которая была всегда, ещё до ЛЛМ. Энергичный и продуктивный джун может отправить на ревью кучу непонятного говнокода, который надо чуть ли не полностью переписать, чтобы он стал более-менее поддерживаемым. А ревьюер не может сказать "всё говно, переделывай", потому что сам джун не понимает, почему это говнокод и как его можно исправить (иначе он бы не был джуном).
А где вариант "Не использую ИИ" ? Я пробовал, честно. Имея 20-летний опыт программирования, мне проще и быстрее написать самому, чем пытаться чего-то добиться от искусственного идиота.
Ну тут зависит от задачи. Простые, но многословные бойлерплейты, к примеру, ИИ напишет быстрее. Хоть бы и потому, что при обучении он "видел" много таких.
Вы сами быстрее не напишете на чём-то новом для вас. Зато со связкой с ЛЛМ стартанёте на новой платформе в разы быстрее именно благодаря опыту и знанию, что именно ожидать = спрашивать. Джун же будет дават задачи уровня "сделай хорошо", как и видим в каментах.
С отдельными методами он часто хорошо справляется, а там где не справляется - можно по старинке написать. Если не устраивает качество решения задачи от LLM, значит ее надо декомпозировать на менее крупные задачи того размера с которым он будет справляться. А несколько строк он почти всегда может уж написать. Я уже не говорю про всякий CRUD, и бойлерплейты которые дают максимальный эффект по ускорению.
Вся суть ИИ в их инструментах
Я смотрю на claude code в GitHub. И сколько там issues, которые висят месяцами. Это же странно, ведь у команды должен быть «безграничный» потенциал ИИ. И проблемы можно закрывать 24/7. Это показывает - что все эти заявления воздух. Пока эти компании не начнут создать проекты на «конвейере» - то обсуждать ИИ как ассистента не смысла.
Все по делу. К счастью, в нашей организации (Samsung Advanced Computing Lab) начальство не заставляет использовать ИИ. Говорит типа "если сможете найти применение этому - Ок, а нет - не парьтесь".
Ваша организация к несчастью на днях откушивала курятину с неким Хуангом и радостно заявила, что ИИ теперь ваше будущее.
Вы путаете золотоискателей и тех, кто продаете кирки золотоискателем.
У нас есть группа по дизайну чипов для ускорения ИИ. Из этого не следует что мы должны использовать ИИ для дизайна этих чипов.
Я вот разработчик GPU для быстрого выполнения трехмерных игр на телефоне. Из этого не следует что люблю играть в трехмерные шутеры сам.
Сюда минусов ещё отсыпьте:
2025-11-02
Производством Samsung будет управлять ИИ. Компания совместно с Nvidia построит фабрику ИИ на основе 50 000 ускорителей
Вы слишком впечатлительны от текстов от журналистов. Еще лет пять назад было несколько статей в СМИ с заголовками типа "ИИ от Synopsys спроектировало чип в Самсунге!" Однако при внимательном рассмотрении выяснилось, что речь идет не о проектировании (на уровне микроархитектуры, регистровых передач итд), а о небольшой (на несколько процентов) оптимизации размещения и трассировки (floorplanning - размещение блоков, placement - размещение стандартных ячеек, routing - соединения). Фишка в том, что автоматическому place&route сто лет в обед - это продавала еще компания Silicon Valley Research в конце 1970-х годов. Проектированием это не является. С таким же успехом можно писать статьи "Microsoft Word пишет романы!"
Программирование с ИИ — это навык совершенно новый. Доверять ему нельзя. Весь процесс превращается в выдавливание из него именно того, что тебе надо (ну, с минимальными вариациями).
И всё же я уверен, что можно сделать так, чтобы получить именно то, что хочется, сделанное именно так, как тебе хочется. Соответственно, долговременных проблем такой код иметь не будет. И это будет даже быстрее, чем писать самому. Вот только назвать это всё вайб-кодингом нельзя никак. Это довольно напряжённый процесс.
И начинать надо совсем не с того, чтобы просить Cursor что-то написать. Опустим историю с начальным шаблоном проекта, тут и так всё ясно.
Перед тем, как просить Cursor что-то сделать, надо структуртровать свой запрос. Я обычно беру ChatGPT и разговариваю с ним, чтобы он мне по обрывочным рассказам создал спецификацию, которую я сохраняю в формате .md. Если это не просто описание измения, а описание классов или других сущностей кода, интерфейсов, подсистем, правил работы с ними, я кладу файл в проект и потом прошу Cursor поддерживать, когда он делает для меня изменения. В спецификации я пишу всё, вплоть до того, как именно хотел бы, чтобы классы тестировались. Если долго делать всё это в одном чате, проще, многие рекомендации ChatGPT помнит и включает сам.
Уже имея спецификации, иду в Cursor, прошу сделать. Тут за ним нужен глаз да глаз, это очень похоже на джуна. Но зато он быстрый, и за несколько итераций обычно можно выжать то, что надо. Все патчи лучше смотреть. Покрытие кода проверять потом самому.
В итоге результат получается довольно толковый и много быстрей, чем своими силами. Но сил это требует много. Делаешь быстрее, но расход сил отдалённо сравним с тем, чтобы написать самому. Хотя автоматическая поддержка документации к коду дорогого стоит, у самого руки часто бы и не дошли.
А о чем статья то? Первая половина банальной информации, которая всем известна а вторая - в чем сложность просить у ИИ писать не много кода сразу, а мелкими кусками? По тексту статьи выглядит так, как будто мы в понедельник с утра запрашиваем у ИИ сразу код за неделю работы и потом неделю его проверять надо, но заказчик говорит вы ж ИИ используете, поэтому вот вам три дня. Я правильно понял? Но вроде бы это не так работает.
Не понимаю, чего в комментах столько негатива к LLM. Я программирую давно, скорость высокая. С приходом LLM моя скорость увеличилась думаю в 2 раза точно т.к. теперь всю рутину по типу написания мелких неприятных функций в стиле пересчёта кучи параметров в куче данных, сложные вычисления во временах/датах и прочее забрали модели.
Я точно знаю, что в функциях, которые не используют ничего экстравагантного внутри себя и их размер не превышает 100 строк кода - не будет ошибок. Модели отлично справляются с такими задачами. Если даже и будут ошибки, то когда функция покроется тестами - я это увижу. А если нужно написать какого то "монстра", и когда не знаешь с чего начать, LLM может дать пример кода, который просто натолкнет на мысль, а дальше я уже сам напишу.
В общем не знаю, как по мне при ограниченном использовании, без всяких курсоров и клаудов - LLM ускоряет работу и при этом код остаётся красивый и расширяемый.
Да, и с курсором то же самое, если каждый раз просить его выполнить задачу ограниченно объёма, хорошо её формулировать и проверять результат.
А про негатив, то он, полагаю, либо у ждавших полного чуда, либо у неё освоивших пока нормально.
Я вообще уверен, что это будущее нашей профессии, как когда-то были языки высокого уровня. И точно не её смерть.
Думаю, здесь просто выплеск эмоций, сходных с теми, что по будили когда-то луддитов станки ломать.
ИИ - лишь инструмент, которым нужно научиться пользоваться. А для этого что - то нужно менять, в первую очередь - в себе. А это нравится далеко не всем, да...
Позвольте узнать, сколько часов разработки у автора? И каким техническим стеком он выстраивал свою работу?
Понятия не имею сколько часов.
Если начинать со взлета ChatGPT 2023-06-01, исключить мелкие проекты и вайбкодинг, то столько добавленных/удаленных строк:
git diff --shortstat "main@{2023-06-01}" "main@{2026-01-01}"
1716 files changed, 101421 insertions(+), 48094 deletions(-)
Стек в этот период времени:
svelte-kit, typescript, к ним прилагается еще несколько десятков библиотек и своих инструментов
Архитектура была FSD, потом сделал свою с Dependency Injection
Библиотека компонентов своя
IDE: WebStorm
ИИ инструменты в основном эти: Claude chat, Claude Code, Gemini CLI, GitHub copilot
потом сделал свою с Dependency Injection
А вот это интересно - TypeScript или JS?
Я использую только TypeScript практически везде в JS разработке, кроме очень простых вещей типа скриптов. Он дает массу преимуществ, которыми глупо не пользоваться. TypeScript добавляет сложности в проект, но здесь нужно задать вопрос: окупается ли эта сложность? Для меня, если проект больше нескольких сотен строк кода, это окупается. А при разработке чего-то сложного я начинаю с типов, это для меня необходимый этап проектирования.
DI у меня больше похож на derived из svelte, никаких классов, декораций и прочих сложностей пришедших из ООП языков. Вообще, то что придумали в svelte для реактивности - это наверное лучшее, что можно было придумать в рамках стандартного JS, в плане скорости и гибкости, если конечно не ломать сам язык, вводя дополнительные компиляторы.
В FSD несколько слоев, и нужно вручную распределять код по ним, а при любой нестандартной ситуации хвататься за волосы и думать куда впихнуть код или как все переделать так, чтобы не пришлось больше переделывать. FSD подходит только для небольших проектов.
DI позволяет сделать только два слоя: слой инъекций и слой фич. Получается, что фичи не зависят от фич вообще, а зависят только от инъекций. Фичи можно объединять в списки (коллекции), из коллекций фич складывать приложения. Граф зависимостей формирует DI; это дает небольшую задержку при запуске приложения, но окупается скоростью разработки и огромной гибкостью.
Необходимо всемерно снимать завесу тайны с так называемого "мышления". Нет никакой тайны, только физика. Мозг - это предмет. Знания - это густопереплетенные хвостики нейронов. Не более! И такие знания есть и у LLM. Это "веса" модели. У человека хвостики, у модели веса. И больше ничего.
Почитал комментарии и тоже решил поделиться своим опытом использования агента. До использования агента мое представление о возможностях его писать код складывалось еще со старых моделей, а так же из... снобизма. Вот тоже сидел и доказывал людям, что ну не может какая-то там нейросетка решать задачи сложнее хелловорлд(условно).
Входные данные:
Есть картографические программы Alpine Quest и Offline Maps, которые имеют свой проприетарный формат тайловых растровых карт *.pgd. Никакой нигде спецификации нет. Программа эта присутствует только на андроид и весьма пользуется спросом в определенных кругах
Есть карты. Много. Большие. В формате *.pgd. Исходников нет.
До использования агента я пробовал ковырять *.pgd, и единственное, что смог сделать сам на основании этого - извлечь по маске все кусочки webp мозайки в riff контейнерах. А сколько их в ширину? Где это описано? А сколько уровней детализации? А какие метаданные есть? А как их извлечь из бинаря?
Ну достал я ручками webp-кучоки. Хорошо. Методом тыка я собрал одну карту в целое изображение. Но проблема в том, что Alpine Quest применяет к этим тайлам афинные преобразования на лету и "натягивает" их на глобус. Это изображение ничего не дает. Оно не ложится на карту. А как его "натянуть"? Где взять матрицу коэффициентов? А границы minLon, minLat.....?
Я понял, что даже опытный разработчик вот так в лоб расковырять имеющийся бинарь карты не сможет.
Взял приложение. Прогнал через jadx. И получил на выходе огромную лапшу и кодовую базу в сотни тысяч если не миллионы строк кода(приложение реально монстр если вникнуть сколько в нем всего учтено и заглянуть внутрь, тогда начинаешь понимать почему разработчики по сей день не могут его портировать на другие платформы). Что дальше? Знания java у меня нет. Попробовал grep'ом пробежаться по кодовой базе поискать всякие ключевые слова из бинаря, функции открытия *.pgd и нашел сотни точек входа, и все они наследуются, расширяются и так далее и тому подобное - все прелести ООП.
Я попросил GPT4.1 проанализировать кодовую базу приложения и разобрать как происходит парсинг *.pgd файла, как извлекаются тайлы, трансформации и т.д.
И он через 10 минут выдал примерный пайплайн, который на 80% соответствовал действительности.
А GPT-5(codex) написал с минимальными правками(но порой с хрустом зубов) полностью рабочую программу, которая принимает на вход *.pgd, извлекает самый детальный уровень, извлекает тайлы, собирает в холст, извлекает матрицы преобразования из pgd и прочие метаданные, применяет трансформации к холсту, режет обратно в тайлы, кладет в *.mbtiles(уже распространенный формат карт), а так же режет не несколько уровней.
На все я потратил около недели по пару-тройку часов в день.
Я понимаю, что код - говно, но опираясь на него средний разработчик уже полностью может оценить пайплайн и написать как надо, либо же можно попросить чистого агента это сделать(надо будет попробовать). И кажется мне, что это это выйдет на ПОРЯДКИ дешевле, чем прийти к разработчику с задачей реверс-инжиниринга программы, бинаря и написания готовой программы с нуля.
К слову. Программа работает отлично, но я заглянул в потребление памяти и ахнул - 13 гб в пике. GPT-5-codex предложил несколько оптимизаций, да приходилось откатываться, пробовать снова, что-то ломалось, но 2-3 часа хватило на то, чтобы в нужных местах почистить мусор, оптимизировать программу и снизить потребление памяти до 500мб хотя одна из карт - это холст размером 11008x11520 в альфа-канале.
Кому интересно, то вот https://github.com/Exieros/PGD-to-mbtiles
Если в pgd_assemble.py как по мне все еще вполне понятно, то вот в pgd_geowarp_mbtiles.py происходит вообще какая-то неведомая магия. Да, происходящее там выходит за рамки проприетарного функционала оригинальной программы и скорее всего так или иначе уже кем-то где-то решалось, но тем не менее - оно полностью решает мою задачу.
На мой взгляд LLM-агенты в будущем будут действительно очень мощными инструментами. Но и результат будут выдавать в соответствии с тем, кто им орудует. За ним надо тщательно следить потому что он может в определенный момент "кивать головой" мол все понятно, а на самом деле вообще начать делать то, что не соответствует задаче, но при этом красиво.
А так же если немного затронуть комментарии выше, то LLM агенты на моем примере показали мне, что это не просто умный фокусник, которые достает из шляпы наиболее релевантные написанные кем-то куски. Я увидел от агента анализ происходящего в декомпилированном коде на основании которого он разобрал формат карт(который точно нигде и никто не разбирал), достал нужные метаданные(что тоже невозможно без полного построения картины происходящего в оригинальной программе), а так же решил задачи уже более распространенные.
Я сначала психовал, потом придумал свой подход. Теперь дружу со второй головой, всё у нас хорошо))) И совет, используйте народные мудрости: например, у какого-то народа есть традиция, что к теме надо подходить из далека, так и тут - прокачайте сначала веса, а потом ставьте задачу. Эта штука ленивая, с одного запроса нормально не заведется, как бы ты его круто не составил.
Полностью поддерживаю автора. И даже сам DeepSeek признался мне в том, что он не умеет думать, а действует шаблонно...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
С появлением ИИ работа опытного программиста стала намного сложнее