Обновить

Заблуждения обывателей о разработке через ИИ. Мнение разработчика

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели11K
Всего голосов 18: ↑17 и ↓1+19
Комментарии30

Комментарии 30

На самом деле ИИ инструментарий быстро развивается и есть решения многих описанных тут проблем.

Я например тоже писал, что код может не соответствать код стайлу проекта. Но это решается простым указанием код стайла. Каждый день выходит, что-то новое, и на текущий момент нужно понимать, что это инструмент и с ним нужно уметь работать. Так, что обывателям следует сначала разобраться, а потом уже делать выводы)))

Указание код стайла забивает и без того никакое контекстное окно

Окна за год на сколько расширились? Интерполируем на Н лет вперёд... :)

А зачем в окне? Если cursor, или какой-то qodo в vs-code, firebase.studio и так далее, они смотрят на файлы в проекте. Можно положить файлик md в проект и он будет его сам читать. Преднастроить агента и так далее))

А при реализации запроса, допустим если, они не понимают, что-то, то изучают проект, например:

А вы думаете, что от того, что md файлик подтягивается сам, он магическим образом исключается из контекстного окна, снижая нагрузку на него? Или что поискать код в проекте окну ничего не стоит? Тот же уровень непонимания как работают ЛЛМ, о котором говорится в статье, собственно

Поискать - не стоит. Подстановка в контекст, само собой, стоит, но это не космос, если следить за логикой в файлах. Agents.md должен быть максимально короткий и ёмкий, так как он тянется всегда. Остальные файлы документации тоже не стоит раздувать (и уж точно не генерить их с ИИ)

Дмитрий, если вы имеете в виду мою ремарку про соответствие принятым в проекте стандартам, то дело далеко не только в код стайле. Тем более, эту проблему можно просто решить, прогоняя линтер поверх ИИ-шной писанины.

Проблема скорее в том, что стандарты и правила в конкретном проекте могут быть какие угодно, ну так, к примеру:
- принципиально не используем какую-нибудь популярную библиотеку (ИИ может всё равно стараться её ввернуть)
- если правим модуль X, дёргаём на пулл реквесте людей A, B, C, чтобы они одобрили, а если модуль Y, дёргаем D, E, F
- на сложных запросах вместо ORM юзаем RAW SQL для удобства отладки
и т.д.

Таким образом, значительную часть работы всё равно придётся делать разработчику. В том числе вычитывать и ревьюить ИИ писанину. Что довольно утомительно, ведь читать код сложнее, чем писать. Особенно если этот код - чужой.

И про это тоже. Код стайлом я обозвал все это. Агенты смотрят на подходы в текущем коде и у вас есть возможность их указать. Не делайте поспешных выводов, изучите инструмент

Какие пулреквесты и все такое, это вы прописываете в ридми проекта, и он в курсе. Сейчас борьба за контекст, правильное исполнение различных MCP и так далее. MCP джиры добавляете, и он тасочку по факту оценит, сходит в фигму за дизайом, изучит дизайн систему, сделает и передвинет в тест. У нас на этом внутренний проект живёт))

Но и да, это не замена разработчика. Это помощник. Но вы не путайте вайбкодинг, с агентами. В firebase.studio за вас и сервера поднимаются и базы создаются, весь девопс через промт сделать можно. Все быстро меняется. Это скорее опастность для джунов

Если у вас там крутая база или микросервисы, это все ему нужно дать для контекста. Схему, или какое-то mcp тоже) А может просто действительно, он не решает конкретно вашу задачу) Одним молотком дом не построить)

Изначально, в статье и дискуссии, речь всё же шла об идее не-разработчику написать текстом, что надо сделать, и получить готовое решение от ИИ. Речь не шла об агентном подходе, - так что это вы не путайте ;)

Что касается агентов, это интересная, но очень обширная тема, которая далеко за рамками моей статьи. Здорово, если кто-то по-настоящему освоил эффективную работу с ними, но как минимум сходу могу назвать две проблемы:

  • агентные системы наследуют все болячки LLM (прожорливость, галюны, лимит контекста, стохастичность и т.п.)

  • эффект "каши из топора": когда агенты не работают "из коробки", и требуется "руками" проделывать большую работу по их конфигурированию и отладке. В итоге "разработка через агентов" может оказаться дороже классической. Хотя начиналось всё именно с идеи экономии времени.

Александр, Вы написали хорошую статью, но Вы боретесь с ветряными мельницами, принимая маркетинговый ярлык за научный термин. Вся ваша аргументация - это точная диагностика болезни под названием "LLM-мания". Вы перечислили симптомы: галлюцинации, стохастичность, зависимость от промпта, проблемы с контекстом. Это ограничения больших языковых моделей, а не "ИИ" как такового.

Проведите эксперимент - замените в Вашем тексте "ИИ" на "ChatGPT и его аналоги" и сразу статья станет только точнее. А теперь попробуйте применить Вашу критику к когнитивно-символьным системам, тем самым, что управляют марсоходами, проверяют корректность микропроцессоров или ставят предварительные диагнозы в медицине, то статья - "рассыплется".

Проблема не в том, что "ИИ не может заменить разработчика", а в том, что статистический автодополнятель текста, каким бы умным он ни казался - это не "разум", а всего лишь инструмент с очень специфической и ограниченной областью применения. Вы бьёте по верной цели, но название у этой цели не "ИИ", а "магическое мышление вокруг LLM".

Спасибо за "взгляд со стороны"!

Я нарочно сделал ряд упрощений, в том числе свёл ИИ до больших языковых моделей на архитектуре трансформеров, потому что основные заблуждения и хайп сейчас развиваются именно вокруг них. В первую очередь старался обратиться к не-разработчикам и избежать переусложнений.

Далее, дело не просто в

замените в Вашем тексте "ИИ" на "ChatGPT и его аналоги" и сразу статья станет только точнее

Проблема, как вы верно заметили, в магическом мышлении, а именно в заблуждении обывателей о том, что основная сложность разработки - это написание кода.

Если помните, лет 10 назад эту же проблему пытались решить через введение no/low code систем, мол если написание кода заменить на перетаскивание блок-схем в визуальном редакторе, то программировать сможет любая домохозяйка. Хайпа тогда тоже было много. Так что дело не только лишь в ChatGPT и аналогах, ИМХО.

Мне нравится переводить термин ИИ как Имитацию Интеллекта. Тогда все становится на свои места. А маркетологов и прочих обухов да блоггеров слушать... не стоит ))

В 2000-х было популярно называть ИИ из компьютерных игр "искусственным идиотом" =)

На самом деле никакой "ИИ" не нужен для того, чтобы, упаси боже, заменять человека. Под этой ширмой строятся персонализированные эхо-камеры и инструменты манипуляции уже не массами, а отдельно взятыми людьми. Выжимать продуктивность будут из нас с вами с помощью этого самого ии.

Дистопия из фильмов Верхувена (Робокоп, Звёздный десант) всё ближе!

Полностью согласен с автором. Я рассматриваю LLM как «умный токарный станок», на котором через постоянные итерации, подобно вращению заготовки, создается деталь. Уже ощущается ограничения медленного интерфейса между человеком и машиной. Вполне возможно, что при внедрении прямого интерфейса «Машина-Мозг человека» итерации будут проходить интенсивнее, и работа будет более значительно продуктивнее, чем сейчас.

Мне кажется тут будет нужна эволюция. наш мозг уже ломается на двух одновременных задачах. Либо нейросети вырастут во что то более стабильное, либо наш мозг перестроится когда будут эти кибер интеграции в мозг.

Совсем недавно знакомому согласился сделать небольшой asp net core mvc проект для курсовой и первым делом решил попробовать этот ваш вайбкод.

Широкими мазками он конечно накинул набросок, но чем дальше шел прогрес - тем хуже был результат и тем больше было нерабочего кода.

Итог: уже на второй день продолжил писать как обычно, по человечески.

Вам двойка, не справились))

Это шутка, но суть её очевидна.

Бабушки, котрым на работу принесли компы и сказали теперь никаких бумажных тетрадей, а всё вносим впк, примерно как вы говорят. Тыкала тыкала, потом выдернула из розетки и всё в тетрадку написала. От беса все эти кампутеры.

На самом деое, я давно активно использую ai в работе, но делаю это с умом, а не пытаюсь стать менеджером агентов так, чтобы они писали код вместо меня.

В этом месяце начал активно менять основной стек с C# на C++ и это настоящий кайф когда у тебя под рукой есть чат в котором можно задавать любые вопросы, просить примеры кода и получать пусть не всегда 100%верные, но моментальные ответы. Иногда спрашивая о чем то непонятном, вопрос за вопросом диалог растягивается на часовую лекцию конкретно по тем пробелам в знаниях, которые мне нужно устранить здесь и сейчас.

И, да... На новом проекте, где мне нужно работать, с win-api, directx, hlsl и т.д. агенты вообще не справляются с написанием рабочего кода, хотя и очень помогают.

Видимо, не быть мне, бабушке, вайбкодером, буду всего лишь хардкорным программистом где-то на задворках индустрии XD

Для переезда самое то, как между языками так и между фреймворками. Что по поводу языков да, а на ассемблере вообще глухо.

Я абсолютный обыватель, вообще не соображаю в программировании от слова совсем. Вайбкодинг меня учить базе программирования по ходу дела и я с удовольствием учусь этому, это во-первых. Во-вторых, мне как предпринимателю вообще по барабану где там и как пробелы стоят, для важно то что б мои идеи визуализировались и приносили мне доход. В третьих, они мне приносят доход. Я уже понимаю что такое фронтенд, бекенд,postgres,docker, и как диплоить на cloud run SQL. Так что я думаю это как ручная работа мастера и заводская.

Вот тут очень неоднозначно. Коммерческая разработка - это, в первую очередь, про понимание основ, сочетание программирования и добавленной ценности (что можно удачно продавать). "Вайбкодинг" никак не учит азам, а скорее даёт готовые решения для несложных задач. Это всё равно что разбирать шахматную партию с сильным движком. Движок конечно очень силён (сильнее чемпиона мира!), но мало чему может научить. Он даёт готовые "правильные" ответы, тогда как самое интересное, и само понимание, на мой взгляд, начинается именно с вопросов.


Почему мне следует ходить так, а не иначе?
Чего хочет мой соперник?
Мне выгодна открытая или закрытая позиция?
Надо ли мне разменивать материал?
Нужно ли рубить флаг?
И так далее.


Компьютерный движок просто скажет "лошадью ходи на e6" (к примеру), не отвечая по-существу ни на один из этих вопросов. С "вайбкодингом" то же самое. ИМХО.

Возможно Вы правы,но я не стремлюсь быть программером. Единственное чему я рад это тому что я больше независим от них, я делаю то что я хочу и очень быстро. На данный момент я навайбкодил ватсап парсер чата из групп для своей доски объявлений. Я незнаю кому это нужно было обратиться чтобы объяснить то что я хотел сделать. Уже не говорю сколько это стоило бы денег и времени.

Я бы ввел новое понятие относительно программирования с AI.

Я считаю вайбкодер это тот кто
берет задачу
помещает её в AI
выкладывает в прод результат без проверки
не задает вопросов или эти же вопросы переадресует самой AI
(по сути никак не влияет на систему - если только со стороны интерфейса и бизнес логики)

почему без проверки? потому что вайбкодер вообще не шарит за разработку, за паттерны, за библиотеки, что такое метод он вообще не курил.

Так же у нас есть джуны/выпускники программисты, которые знают базу или знают её поверхностно, они могут так же иметь коммерческий опыт
они так же вайбкодят и не проверяют код

А если студент генерирует пример кода для его изучения, и потом применяет учась, это аналог того как мы когда то копипастили с форумов.

Если вводиться ревью кода, правки ручные кода это уже какой то вайб-тимлид-кодинг

А если сеньор использует AI и делает уверенные решения, например анализирует код, или пишет наброски чтобы потом написать своё решение, или разбирает либу потому что документации нет итд. или даже допускает сгенерированный код в прод но он в нем уверен и написал бы точно так же.
короче где AI никак не увеличивает ошибки в коде.
То это уже совсем не вайбкодинг, это что то другое и пару лет назад такое в некоторых командах не поощряли, явно ровняя к вайбкодингу.

Или вот, тот же сеньор полностью вайбкодит проект mvp для показа +- системы или просто для сьемки видеопрезентации потом. хотя сеньор тут необязателен.
В общем опять же такой вайбкодинг вообще не опасен, если продовый вариант потом сделают нормально а этот черновик выбросят или заюзают как инференс для разработки UX.

важно то что б мои идеи визуализировались и приносили мне доход.

(Слюнявя карандаш, записывает в тетрадочку:) Гражданину @Umnyiне важно, есть ли в навайбанном им коде уязвимости, и не украдут ли мошенники честно заработанный им доход.

Мне прям интересно, что же это за вайбкоженый зверь такой, что приносит доход. Я почему спрашиваю - сколько ни просил показать проект который реально приносит доход, а не потенциально его принесёт, мне такого так и не показали.

Часто делаю код нейросетью, а потом в конце недели смотрю назад и оказывается что проще было сделать руками.

Частично это постзнание. Но ощущение что был полным дебилом

По моему опыту, выигрыш есть только в больших тасках которые часа на 4+ выполнение без ИИ.
Даже с ревью кода, даже если ты напрочь забыл что там в либе, (те время на ручной поиск пруфов), даже если ИИ выдал говнокод.
Всё равно это ускоряет, это уже готовый черновик, который ии выдал тебе за 20 минут, при правильных промтах вся инфа по задаче и коду и сам черновой вариант. НО если ты знаешь слабые места этого генератора шаблонов. Например в ассемблере гпт 5 сильно слабее чем на питоне. А при правильных промтах можно получить более подходящий черновик (ускорив себя, и поработав руками там где реально надо).

А когда таска на 15 минут от силы подправить интерфейс, ну может 30 чтобы вспомнить свойства. ИИ лишь замедляет.
Первое, иногда там пять минут надо подумать чисто, и пять на написание
ИИ выдаст говно-верстку которая имеет лишние стили, шаблоны, сделана не по уму а реально как джун с гитхаба.
Это все нужно переделывать, считай 95% выбрасывать, плюс время на написание этого промта, плюс скорее всего первый блин будет комом и из за ленивости ты попросишь его попробовать ещё раз. и это уже не 15 минут а куда больше.

Ну и оценка тасок, тут вообще рай и автоматизация. пропустил задачи с кодом или просто задачи, получил оценку по времени, доп вопросы по тз (если штат маленький а таски пишет чел который далек от айти - упрощает значительно). дальше можно прикинуть уже от какой таски начнешь двигаться, какие оставить на более длинные сессии.

В общем всё сводится к промтам и к обьективности оценки этих вероятных (не говорю о правильности) решений.
Как писал я в своей статье, даже перестановка требований уже может вызвать галюны, и как пишет автор текущей мы разработчики, продумываем системы - в том числе и как использовать инструменты, какие инструменты.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации