Комментарии 33
Автор мусолит очень простое понятие: эффект низкой базы. Где низкой базы уже нет - там визгов восторга от ИИ особо и не слышно.
У меня то-ли какой-то неправильный AI, то-ли неправильные задачи. Я увидел огромные бенефиты в ситуации когда нужно сделать некоторый exploration - то есть нужны общие знания, но не конкретика.
А каждый раз когда мы применяли ИИ к конкретной инженерной задаче - получалась чушь. И общее время на решение только росло...
В принципе, на текущем уровне развития - все эти помогающие модели и чат-боты напоминают мне студента-недоучку, который ровно перед экзаменом прочитал учебник: он говорит правильные слова, и даже в нужном порядке - но совершенно не понимает что он творит. Преимущество только одно - он прочитал перед экзаментом тысячи учебников по всем отраслям знания.
А, ну да - еще есть успехи из серии "идиотизм, но пусть будет". Например - соседи показывали как у них AI генерирует юнит-тесты для DTO-классов, тестируя геттеры и сеттеры. На наш вопрос: "Нафига?!" - они пояснили что эффективные менеджеры решили что 85% кода должно быть покрыто юнит-тестами и без этого пайплан блокируется... Соответственно - правильное решение тут: лечить голову менеджерам или выгонять их. Но посколько в этой конкретной психбольнице, они - уже начальство, то заставлять ИИ делать бессмысленные тесты геттеров, конечно, лучше чем заставлять делать это живого инженера...
А еще можно обратить на данные, на которых ИИ собственно учится.
В инете полным полно примеров, как распарсить json, как получить подстроку из строки, как присобачить какую-то форму. Но примеров со сложными задачами - практически нет. Если есть исходный код сложных проектов на гитхабе, то там явно недостаточно описано комментариями, что именно делает тот или иной участок кода.
Поэтому так и будет - хорошо описанная база, причем даже не джуниор левел, а стажер, отдельными кусками отдельные часто встречающиеся задачи мидлов, и почти ничего для всего остального.
Кстати не соглашусь. Я пробовал использовать библиотеку SDL с подсистемой haptic - и в Гугле хороших примеров в не очень много. Chatgpt сразу написал более подробные и релевантные примеры кода, чем были в документации и это было быстрее чем искать информацию в Гугле.
В итоге, правда, нейронка перепутала unsigned short с signed и документацию я всё равно читал, но уже более целенаправленно типа "какие аргументы у функции F"
у меня действительно есть сомнения, что chatgpt генерирует код, а не предлагает уже готовый, который где-то видел. А видит он не только google.com, но например и github
Он однозначно генерирует код, потому что я использовал chatgpt чтобы написать код, который парсит базу и данными из нее тегает локальные изображения. Такого для этого сайта (и базы) просто никто не делал, не то что в открытом доступе - просто нет.
Да, конечно, можно нагуглить миллионы проектов, которые с помощью pandas парсят csv и пережимают только нужные столбцы в parquet. Но по факту, чтобы получить на вход пример 10 строчек базы и выдать код, который из этой базы забирает только нужные колонки - это нужно уметь делать 2*2. Лично я за день (с нулевыми знаниями питона) не осилил даже распарсить csv-шку, буквально через неделю вышел chatgpt и "переписал" мой калечный ahk-скрипт на Python.
Основной плюс для людей, которые к программированию не имеют отношения, это то, что ты даешь пример входных данных и пример того, что хочешь получить в ответ. Код, который это делает, "изобретает" chatgpt. То есть всю теорию языка, о том какие там переменные, массивы, инклуды с эксклудами и прочая ботва просто пропускается, как ненужная информация.
Аналогичным образом я "делал" саундборд для Mumble-сервера. Просто скормил логику работы, как я ее себе представляю. Данные сервера. Получил в ответ два скрипта на ruby и питоне. Я до своего запроса к ChatGPT даже слова "ruby" не знал. За день вымучил полностью устраивающий меня "продукт". Работает.
Запрос и ответ
Запрос:
I have a headless Ubuntu Server 24 running Mumble server as a service:
I want to make a simple soundboard that will play sounds on the server I see multiple components:
1) Web page that will allow picking which sound to play and in which channel
2) Server-side "client" that will actually join the channel and play the sound
Ответ (без кода, чтобы не раздувать простыню, просто "шаги"):
Step 1: Set Up a Web Interface
We'll use a basic web server (e.g., Flask in Python) to handle HTTP requests for triggering sounds. Users will access this page, pick a sound and channel, and the server will handle the rest.
<...>
Step 2: Create a Mumble Client Script to Play Sounds
We'll use the mumble-ruby gem for creating a Mumble bot that can join a channel and play sounds.
<...>
Step 3: Connect Web Interface to the Playback Script
In app.py, the play route should now call the Ruby script. When a sound is triggered on the web interface, app.py will run play_sound.rb to play the selected sound in the chosen channel.
Да, само-собой, первая версия скрипта не работала. Пришлось ее допиливать, скармливая ошибки и пробуя ответы ChatGPT. Например, оказалось, что "mumble-ruby gem" протух 9 лет назад и не умеет современный tls. Это тоже пришлось исправлять. Но я это делал с помощью ChatGPT и без какого-либо понимания, что там вообще с этим tls\ssl не так.
Например - соседи показывали как у них AI генерирует юнит-тесты для DTO-классов, тестируя геттеры и сеттеры
Из серии "зумеры изобрели коммунальную квартиру". Раньше этот вопрос как-то решался банальной кодогенерацией. Причем детерминировано. А сегодня чтобы выполнить ту же задачу, но уже с недетерминированным результатом нам нужен ИИ и датацентр с сотнями карточек Nvidia. Тут уже не разберешь, то ли рывок, то ли уже прорыв.
Нет, геттеры и сеттеры им - хвала богам - генерирует Ломбок. Но "тестить все-равно нужно" - ибо менеджмент сказал что не должно быть в приложении больше 15% кода не покрытого юнит-тестами. Аргумент что это покроется интеграционными и E2E тестами - не подействовал. В представлении начальства - чем больше процентов покрыто юнит-тестами, тем лучше работает система... Как говорится - "Каждая сложная проблема имеет простое, легкое для понимания, быстро реализуемое НЕПРАВИЛЬНОЕ решение" (C) Мерфи.
Раз уж зашла речь про ломбок, у него в конфигурации есть возможность указать, что на все сгенерированные методы должна добавляться аннотация @Generated , а у тулы, которая считает процент покрытия кода, скорее всего есть возможность указать, что код, помеченный такой аннотацией, необходимо игнорировать при подсчете.
Так оно же натренировано в том числе и на конкретных решениях? Нормально вроде решает. Есть только какая-то странная особенность. Довольно часто делает какую-то очевидную глупость. Недавний пример, ставлю задачу отрефакторить код - переделать классы клиенты api, которые появлялись постепенно, перенести в родительсикй общий функционал. Делает все хорошо. Только вот по неизвестной причине просто выкидывает некоторые методы, которые очевидно нужны. Указываю на это - поправляется. И именно вот таких ошибок странных достаточно. Их поправить самому проще, иногда можно указать - поправит, иногда феерически тупить начинает на откровенной ерунде. Как-будто специально ограничили.
"Вот раньше как говорили? Будет электричество, будет счастье! Так вот, электричество появилось, а счастья как не было, так и нет!" (с) Народная мудрость
ИИ это всего лишь инструмент, а будет ли он полезным зависит от опыта специалиста и угла искривления его рук. А если опыта нет... «Техника в руках дикаря — груда металлолома»
Не знаю, буквально вчера попросил chatgpt написать код, который бы ошибки, которые выдаёт симфони валидатор, приводит в нужный формат. Нужный формат описан в openapi спеке, которую я скормил чату в yaml формате. То есть, по сути найти компонент в спеке, смапить поля из ошибки валидатора в компонент из спеки. Не справился.
Для любого разумного индивида очевидно, что ЛЛМ не умеют и никогда не будут уметь писать новый код. Технология не предусматривает. Соответственно, всё, что они делают, это расшаривают элементы готового кода между человеками.
Раньше считалось правильно расшаривать код через библиотеки и фреймворки. В крайнем случае — через форумы и стековерфлоу. Но это же гомосапиенсы с планеты Земля. Они додумались расшаривать код через статистические алгоритмы с рандомизатором, да ещё поставить на кон половину экономики.
Для любого разумного индивида очевидно, что ЛЛМ не умеют и никогда не будут уметь писать новый код.
А сколько программистов на планете Земля пишет новый код, а не компилирует куски старого под новую бизнес задачу?
Понятие "новый" может оказаться плодом человеческого разума, не имеющего никакой объективной характеристики.
Все так. Вот я на JS пишу редко. Когда надо - мне чатГПТ ок так пишет код. Но нужно перечитывать за ним. Быстрее получается чем гуглить. На питоне я пишу постоянно и не чувствую никакой пользы. Вырубил копайлот к чертям, чтобы не тормозил.
ИИ просто шикарен. Постоянно использую для написания тестов, генерации данных, или каких-то других простых но занудных вещей. Иногда подкидывает интересные идеи, о которых я просто не догадывался. Это не серебряная пуля, но значительно ускоряет разработку.
По моему опыту, самым продуктивным способом использовать ИИ оказалось попросить его сделать code review:
- Чушь от ИИ можно просто проигнорировать, ее не надо исправлять, как если бы я попросил написать сразу код.
- "Думает" ИИ совсем не так, как я, поэтому иногда обращает внимание на вещи, о которых я сам здесь и сейчас никак бы не подумал.
- ИИ всегда готов неутомимо рецензировать исходники, тогда как коллега - нет.
Странно, что о code review в статье упоминается как-то совсем косвенно, хотя эта стадия разработки ПО однозначно выигрывает от ИИ без видимых негативных эффектов (если разумно подходить, не отказываясь полностью от обычного рецензирования человеком).
И, кстати, в этом варианте ИИ может общаться с разработчиком на родном языке, переходить на английский не обязательно.
Вот когда код от ИИ напрямую в прод литься начнет, минуя кожаных мешков, тогда и поговорим. А до этого навыкладываем в репу логических загадок, на которые ни одним обучением априорно не натаскаешь.
Мы, человеки, столько граблей в коде понаоставляли уже, что 14% задач, которые этот ваш ИИ якобы может решить полностью, никого не спасут :)
Кроме того, ИИ же -- тупая железяка: ТЗ качественно отработает, да и только. А все эти "да тут совсем другое в виду имели" кто имплеменить будет?
Откуда вы взяли 14%?
Непосредственно из приведенной статьи:
он решает 13.86% всех задач без какой-либо помощи
И, что характерно, по закону парных случаев именно сегодня в линке лентой принесло как раз про Devin:
We just tried Devin out. For the uninitiated, Devin is a mostly-autonomous AI software engineer.We asked it to fix a minor bug we were having with the placeholder text for an input. It proceeded to attempt to drop multiple tables from our database.
Хорошая статья, полностью согласен. Я из тех, кто не пугается того что ИИ заменит разработчиков и они потеряют работу. Наоборот. Он их дополнит и заменит большие коллективы. Как синтезатор заменил оркестр.
Разработка демократизируется в том смысле, что архитектор будет работать с ИИ-мидлами. И талантливый инди-разработчик сможет потянуть более серьезные проекты.
Я в Яндекс-браузере стал использовать поиск-нейро. Не знаю, насколько это можно считать ИИ, но эффект очень хороший. Мне выдается сразу конкретный ответ, не надо прочитывать кучу ссылок и решать, подходит или нет мне данный ответ на stackoverflow или нет.
Горькая правда о программировании с использованием ИИ