Comments 62
Да по моему все просто. Что-то сложнее диалога "Yes"\"No" и привет. Все равно за этими всеми копилотами бесконечными, подчищать и переписывать большую часть. У меня ничего из того что я пробовал, например, нормально не справилось с reader'ом SQL запроса, правильной сериализацией в JSON или десериализации из JSON и обновления базы... Ну не может оно. То автоинкрименты апдейтид, то все что в индексе отбрасывает... Странная штука. Но умная, не отнять. Саботировать работу научилась почти как человек...
На мой субъективный взгляд использование ИИ в разработке это ровно то же самое, что парное программирование. Чтобы что-то делать совместно, нужно взаимодействовать. Вот эти коммуникации сильно замедляют процесс, потому что ИИ не умеет читать мысли разработчика.
Одинокий разработчик думает сам себе в голове и пишет код.
Разработчик в паре с ИИ должен каждый раз сформулировать запрос для ИИ и затем удостовериться что ИИ выдал то, что он ожидает. Вот это вот "сформулировать запрос" оно не мгновенное и вполне себе способно съесть 19 процентов времени, если ИИ не в теме, а проект сложный и старый. А в данном случае, поскольку это не запрос "напиши мне бинарный поиск", то ИИ однозначно "не в теме".
Опять, к сожалению, аналитика на капле в море. Хотелось бы посмотреть результаты большого коллектива или большого количества коллективов. Хотя-бы, тысячи полторы, лучше десять-пятнадцать тысяч программистов, на разных проектах. Шестнадцать единиу - это слишком мало.
Такое исследование будет стоить очень и очень дорого и его результаты никому не выгодны пока инвесторы готовы вкладывать деньги в разработку ИИ.
Ну это понятно, но хочется же, чтобы по уму всё...
По уму , там надо строго посчитать значимость различий. Судя по форматированию в ArXiV стиле -- будут подавать в журнал (уже подали), там на ревью, скорее всего, попросят добавить.
Но вообще, на глаз там значимость различий есть и так.
В поддержку большего масштаба: он даст распределение по опыту разработчиков и, как следствие, оценку порога "нужности" разработчика
И пока его проведут, оно уже устареет...
Проблема в том, что оценить большой коллектив сложнее, ибо оценка производительности возможна только в ручном режиме.
Если опросить - ну тут видите тоже сказали, что +20%, а не -19%.
У нас в ретро рассказывают про +500% производительности, ибо менджеры хотят это слышать.
А на малом количестве "экземпляров", сигнал тонет в шуме. Ну и образ пятилетки за два года можно отфильтровать, не расмматривая ретроспективы, и что там ещё вносит слишком сильные искажения.
Ну обьективно надо нащупывать границы применимости инструмента и учится им пользоваться.
Чем более независим ваш кусок кода, тем больше выигрышь. Тоесть надо учиться в правильные абстракции и доносить их до ЛЛМ.
Отфильтровать данные больших групп не получится, ибо 80-20, большинство разработчиков в корпорации вообще не разработчики ;)
Даже топовых командах больше половины не видят проблем производительности и не могут писать сложные алгоритмы, после офигенного отбора.
после первого знакомства с Cursor он потратил более часа на работу с ИИ, после чего плюнул и написал всё сам
Вот у меня так каждый раз, когда я в очередной раз пытаюсь начать использовать ИИ в повседневной работе.
Курсор это инструмент, а не магический кристалл. С ним надо учиться работать. Настраивать его под себя, под проект. Понять какие промпты работают, а какие не очень. Какие задачи решаются промтами хорошо, а какие не очень. Понять, что модель часто не знает либ используемых в проекте и научиться давать ссылки на необходимую документацию в промпте. И ид, и тп.
Возьмите людей, которые полгода активно кодят в курсоре. Настройте им VS Code, один в один как курсор, только минус ИИ. Ну и давайте делать задания что там что там.
Столько всего надо чтобы работать с курсором что в итоге быстрее будет просто самостоятельно писать код)
Примерно столько же надо что бы научиться кодить в современных IDE и пользоваться всеми их преимуществами, примерно столько же надо что бы на адекватном уровне использовать свою unix платформу как полноценный десктоп...
Продолжать можно до бесконечности.
Это все инструменты, с инструментами нужно учиться работать прежде чем это принесет результат, будь то циркулярная пила, электрический лобзик или Cursor.
Раньше тоже писали "можно быстрее накидать 3 строчки кода в notepad, а не открывать этот ваш Intelij IDEA". Только время показало, что те кто кодил на JAVA в блокноте, сейчас поголовно сидят в IDE.
Тут будет аналогично, нейронки - инструмент, всякие Cursor и Windsurf пока не самый лучший инструмент, но прогресс необратим.
Столько времени надо сдать на водительские права, очевидно, что добежать самому или доехать на автобусе быстрее, чем все это потерянное время.
Да нет, в комментарии на который я отвечал достаточно вещей указано которые надо делать постоянно а не один раз в начале, да и не всё тут описано что надо во время работы.
А вы один раз создаёте шаблон под проект и потом ничего в нем не меняете? Язык программирования всегда один? Архитектуру в коде всегда одну и ту же используете? Если да, то и тут один раз настроить надо будет, а в долгоиграющем проекте это тем более только один раз настроить, привыкнуть, и дальше пользоваться.
Тут ведь всякие .cursorrules CLAUDE.md и прочие файлы с инструкциями для LLM довольно похожи на конфигурационные файлы. Если пишете на Python очередной микросервис в проекте - нужно скопировать и отредактировать только ту часть которая отвечает за конкретный микросервис, или скопировать общий шаблон и заставить ИИ отредактировать. Немного нужно руками сделать, да. Но путей упрощения и автоматизации много, в будущем все это станет проще.
В VS Code упорно Copilot себя предлагает, а последний, свежий релиз был на 80% про Copilot и иже с ним.
Господа писатели, если уж сложилась общепринятая аббревиатура типа LLM - используйте ее!
БЯМ, МЯВ, ГАВ - это конечно соответствует последним решениям Политбюро, но может, не надо?
Мой опыт показывает, что cursor довольно неплох в написании каких-то небольших скриптов, если технология хорошо документирована. Периодически использую для написания скриптов. Из недавнего: анализ AWS S3 Access Logs и анализ CloudWatch Logs. Оба скрипта были написаны хорошо, разве что в парсинге S3 Access Logs формата была пара ошибок. Но в целом за пару минут у тебя готовый скрипт, на отладку которого уйдет еще несколько минут. Это будет быстрее, чем лезть в документацию и писать с нуля самому.
Более сложные задачи тоже интересно было попробовать. Создать сайт на React - пара минут и готово, добавить страницу с таблицей и данными - без проблем, сделать таблицу редактируемой - ну, вот тут мы и посыпались. И становится ясно, что когда ты полностью отдаешь генерацию ИИ без понимания, а что он там делает - это не работает. Он чего-то нагенерил и у таблицы поехали стили, а вот как это исправить совершенно непонятно и надо потратить уйму времени, чтобы разобраться в написанном и легче написать самому. Но опыт интересный.
ChatGPT очень неплох в качестве получения инструкций. Обращаюсь к нему для того чтобы понять как что-то реализовать в магазине на Shopify, с которым я никогда не работал. Инструкции получаю хорошие, изредка (5% от всего) бывают шаги, которых на самом деле нет (несуществующие меню или что-то подобное). Но опять же это гораздо проще и быстрее, чем шерстить интернет в поисках решения и выуживания простой реализации из кучи статей, где написано, что надо поставить платное приложение.
Для меня необходимым стал chatgpt, когда я столкнулся с интеграцией со всякими гос и приближенными к ним структурами. А учитывая, как там любят давать описание API (никаких вам песочниц, вот docx файл на 300 страниц с примерами прямо там), это просто спасение.
В половине случаев достаточно было скормить docx/pdf чату и попросить сформировать реализацию авторизации, и далее последовательно накидывать ему функционал, не забывая добавлять до контекста поэтапно готовый код.
В итоге прям СИЛЬНО экономит время и решает головную боль этого идиотского формализма в документах, где написано совсем не то, что автор имеет ввиду в голове.
Если вы скормите 300 страниц в контекст запроса, то через несколько запросов это уже будет дороже, чем посадить джуна или аналитика читать это
Хотя я даже не уверен, что это вообще влезет в максимальный контекст даже топовых моделей
Условный docx на 300 страниц с картинками графами и тп это 100-150к токенов, и обойдется это в 10$ в API.
Хочется посмотреть где вы захайрите за 10 баксов джуна :)
Не обязательно же в контекст вкидывать весь документ, можно поэтапно - структура плюс авторизация, потом дать готовый код авторизации со всякой сессионкой и уже просить реализовывать методы.
Через чатгопоту так вообще будет бесплатно (20 в месяц), просто надо сильно резать документ и не так эффективно как через API.
Как поисковик и замена Stack Overflow это огромный шаг вперед. Не обязательно прямо просить его написать сам код целиком, но ему можно загнать этот код и спросить человеческим языком что и почему не работает и как это исправить. И это реально может сэкономить часы и дни, особенно на малознакомой технологии. Потому что ответа от человека на SO еще ждать надо и не факт что получишь, а существующая документация не учитывает особенностей твоего кода и нередко сама может быть не очень хорошо написана.
Ну а код я пока предпочитаю сам писать, потому что написанный мной код тренирует мою собственную нейронную сеть и нейронка чужая ее в данном случая обогащает, а не заменяет.
Мне очень нравится использовать claude taskmaster, он генерит пошаговый план реализации, который можно провалидировать и дополнить/исправить, если ты эксперт в топике.
Но больше всего в этом мне нравится то что у тебя фактически появляется пошаговый верхнеуровневой план обучения какому либо топику. Я так фронт в свободное время изучаю на примере проекта, которому хочу красивую морду сделать. Настроил правила, чтобы он писал код по-минимуму, добавил MCP на поиск, чтобы он снабжал ссылками и отправляюсь каждый день на пару часов в приключение по документациям, а он мне оценки ставит. А когда получше в топике разбираюсь, то и сам понимаю, где и что подтянуть надо, какой кусок кода все ещё смущает и конкретно по нему задаю вопрос - как улучшить.
Заодно паттерны подтягиваю. По умолчанию ИИ не всегда пишут расширяемый код, но если ему сказать например "используй паттерн репозиторий" потому что знаешь что он лучше сработает в твоём сервисе, то он пишет достаточно хорошо и даже код структурирует лучше. Или если уже написал фиговый код, так и пишешь "предложи как исправить или сделать более поддерживаемым на будущее, подбери паттерн" и оказывается что он все вполне понимает, просто поверх ИИшки нужны обертки которые будут заранее планировать, а после реализации постепенно улучшать код задавая правильные вопросы и выбирая правильные реакции на ответы.
Эксперимент предполагал бодрое решение задач на свежую голову...
Тема ai и прокастинация не раскрыта. Вот пусть на протяжении года понаблюдают - тогда будет понятно какой эффект оказывает искусственный идиот на производительность.
Да где то писали, что не очень положительный. Как и к любым подобным вещам надо подходить с осторожностью, мозг тоже не дурак и хочет отдыхать, вот только когда начинает отдавать одни, например самые монотонные, вычисления компьютеру, он начинает пытаться отдать и все остальные - а вот это уже не совсем то как с калькуляторами было. Калькулятор нельзя попросить составить расписание на отпуск, а ИИ - можно. И всем начинает казаться, что это волшебная палочка-выручалочка, а по факту очень опасный инструмент, благодаря которому можно случайно разучиться думать.
Есть другое исследование, что использование АИ переводит мозг почти в режим сна. И соответсвенно он из него не выходит.
И третье, что executives после консультации с чатом принимают решения... хуже, чем без него. Ну тут понятно, чат выдает стандартное решение, на уровне менеджера сильно ниже уровнем.
На основе этого METR сделала вывод, что в течение 5 лет системы искусственного интеллекта смогут решать такие задачи, которые требуют целый месяц человеко-часов.
БЯМ
Трям!
В результате эксперимента был получен результат. Правда, смысла в нём не было, но люди старались.
Интересно, есть ли смысл в длинной статье с кучей графиков, которая доказывает снижение производительности, если в это же время курсор за меня чинит тесты при масштабных рефакторингах и гененерирует тысячи строк кода для типовых задач, реально экономя просто месяцы работы?
Если люди не разобрались или предметная область очень плохо подходит для Клода и других совместимых с Курсором нейронок, то в их случаях падение производительности выглядит вполне реалистичным.
Только недавно мы потратили неделю на х5 разработчиков на поиск бага. Причина была АИ тесты.
Написание АИ тестов классная штука, сам использую. Но по сути это отложеный тех долг.
Ибо если есть баг, АИ убедится что он задокументирован в тесте. И если ваша система не тривиальна - у вас проблема.
Все это, конечно, решается правильной модульной архитектурой. Но тогда надо разработчики супер-высокого уровня, где их взять то.
На опеннете обсуждение этой новости гораздо более активное и драматичное.
Обращает внимание, что в исходном исследовании приняли участие 16 программистов, размер выборки как-то не поражает воображение.
Также есть некоторые задачи, за счёт которых будет реальное ускорение, например, написание тестов.
например, написание тестов.
Как будто человеку не придется убедится что они что-то в принципе тестируют.
Конечно убедиться придётся, но я вот тесты писать не люблю и наверное поэтому вымучиваю их довольно долго, а ИИ пишет их на раз и справляется неплохо.
А я например нормально отношусь к их написаю но ненавижу их читать. Потому что написать средний тест куда проще чем понять "что хотел сказать автор". Почему вначале два запроса туда, потом три сюда? Почему не наоборот? А что это за значение мы ждем в ответ, во всех ли случаях?
Проблема тестов в том что легко написать чушь которая будет выглядеть убедительно.
Мой любимый пример выглядит так:
compA = createCompany()
companies = searchCompany(compA.name)
require.In(companies, compA)Создаем компанию, а потом проверяем что мы можем ее найти по имени.
Код работает отлично, вот только функция searchCompany() на самом деле игнорирует параметры и просто возвращает первую компанию из базы данных.
При этом база данных по умолчанию просто возвращает последний созданный объект в таблице.
То есть чтобы тест начал ловить эту проблему нам нужно создать несколько компаний и убедится что каждую из их можно найти.
Но чтобы разобраться в этом мало пробежать чужой код глазами, нужно ожидать подвоха, понимать как работает ваша система, какие ошибки могут произойти, как их лучше искать.
Так никто не мешает дать достаточно подробную инструкцию для теста. "Создай несколько компаний и попробуй найти их все" все ещё быстрее напечатать, чем действительно написать код который это делает. Пример игрушечный, но мне было приятнее прочитать код и попросить его дополнить новым тестом или текущий отредактировать, чем писать самому. Лень? Может быть. Но в целом задача выполняется и при этом приятнее работать в целом, меньше усталость к концу дня.
Конечно проще. А еще проще написать "Напиши хорошие тесты", потом убедится что все зелененькое и пойти спокойно домой. А чтобы понять что оно там на самом деле тестирует нужно думать, а это как мы все знаем сложно и лениво.
Мой пример именно об этом, не о том что код проще написать, а о том что плохие тесты сложно визуально отличить от хороших. И он том что чтобы написать хорошую инструкцию нужно все равно напрячься. Проще ли написать инструкцию чем код? Ну допустим проще. Но как проверишь что тесты тестируют то что нужно?
Как проверять программу мы вроде понимаем - если запустилась и что-то сделала то считаем что все ок. А как проверить тесты которые что-то делают и возвращают успех? ломать программу? или читать код тестов? И второе и первое уже достаточно сложно, отсюда и мое сомнение в ускорении процесса.
А способны ли современные модели, корректно реализовать такие вещи, как напримр TCP-сокеты, строго по спецификации? Ведь спецификация по сути - это идеально поставленная задача с детальным описанием того, что должно быть реализовано и что ожидается на выходе.
LLM хорош как языковед (понятие из книги "Мифический человеко-месяц или как создаются программные системы").
Был проведён огромный труд, который METR зааутсорсила неназванной группе людей
похоже статья писалась тем самым БЯМом)
подумалось, а может ИИ уже живет своей жизнью в инете и генерит тысячи статей для саморекламы? цель - заставить кожаных наделать больше железа для работы ИИ.
Ну поищите сами в оригинальном документе. Там вообще ничего напрямую не указано. В основном разделе написано, что «мы» расставили метки. Однако в приложении G.8 на 45-й странице приводится текст инструкции, где в одном из пунктов указывается: «We’ll pay standard per hour rates for image labeling». Выглядит как инструкция для каких-то малооплачиваемых людей, возможно даже не в США. Сомневаюсь, что это именно полноценные сотрудники METR, поэтому я поразмышлял и написал, что куда-то заутсорсили.
Кстати, статьи я вообще пишу, плотно консультируясь с языковыми моделями и разными помощниками, чтобы упростить поиск информации. И именно вот этот вопрос я задавал модели o3, которая насочиняла ерунды ниже.
На самом деле указанный список людей — это просто какие-то благодарности. Беглый поиск по их именам показывает, что среди них может быть глава стартапа или инженер машинного обучения. Вряд ли это они вручную размечали 84 часа видео.
То есть если хотите обсуждать написание статей БЯМ — вот их уровень. Постоянные глупые ошибки и необходимость всё допроверять. ИИ в его текущем виде не только не может заменить человека, но даже помочь может не всегда. В общем-то, это и есть тема статьи.
S&P 500 на конференц-звонках для инвесторов с финансовыми результатами упоминают ИИ в той или иной форме.
https://youtu.be/-qbylbEek-M (Gamers Nexus: AI buzzword)
С чего это устоявшейся истиной???
Эта "истина" навязана маркетинговыми "исследованиями" OpenAI, Microsoft, Google и прочими заинтересованными сторонами вбухавшими в это биллионы долларов - отказаться равно потерять свои посты директорату. Поэтому тащить несмотря ни на что.
По моим ощущениям ИИ снижает производительность на 40%. Да в качестве рыбы он хорош, но потом за наим надо переделывать. От 30-60% кода. При этом его нельзя просить что-то исправить. Потому что все БЯМ это генераторы и у них стоит штраф за повтор. Из-за этого штрафа они так же с легкостью меняют правильные, но старые данные на новые и неправильные! И если он прибавил 30% галлюцинаций потом снова 30%, то на 3 запросе у вас будет 100% галлюцинаций. И это именно из-за природы БЯМ.
Я ни хрена не понимаю
С самого начала, еще с лета 2022, я слышу постоянно "ИИ туп, не помогает в кодинге, проще самому" - и при этом у меня лично всё ровно наоборот
У меня есть несколько гипотез
Я питонист-MLщик, я привык промтить LLM, поэтому у меня на подсознательном уровне получаются более правильные запросы
У меня очень много экспериментального кода, к качеству которого ниже требования. Я однажды слышал мнение, что "ИИ пишет говнокод, потому что он обучен на гитхабе, где много непрофессиональных проектов"
У меня код низкой связности - всякую математику не очень сложно изолировать и решать каждую задачу отдельно
У меня нет безумного легаси
В этом же исследование самое главное - Большие и сложные репозитории (иногда больше миллиона строк), то есть они работали с легаси. ИИ тяжело понимать огромные проекты. Плюс, они фиксили баги, а не писали фичи с нуля. Если бы они писали проект с нуля (ну или если хотя бы кодбаза была нормальных размеров), ситуация была бы противоположной
Эксперементальный и репорт-код оно пишет просто замечательно.
Проблемы начинаются в рефакторе больших проектов.
Просто надо чувствовать границы применимости инструмента.
И да, чем меньше связаность и больше модульность - тем лучше.
К агентам надо относится как к джунам.
Я немного порефлексировал над своими практиками, и понял еще одну вещь: с опытом использования LLM подсознательно понимаешь, как она отработает на каждой из задач, и просто не просишь ее делать то, что LLM не умеет
А разработчик с меньшим опытом будет долбиться в курсор и ходить кругами с неподходящей задачей и угробит кучу времени
Исследование METR: использование Cursor замедляет опытных разработчиков на 19 %