Pull to refresh

Comments 142

Спасибо за статью.
Предполагаю, что вы не очень хорошо понимаете тематику :)

Попробую объяснить простыми словами.
Как руководитель отдела разработки, я за внедрение ИИ в виде помощника - это облегчает труд разработчиков.
Вся команда у нас использует GPT и аналоги для получения "второго мнения".

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

А еще ИИ галлюцинирует, когда не знает ответа :)
И это частое явление и без экспертизы вы просто убьёте даже рабочий проект ;)

Спасибо за адекватный комментарий (кармы не хватает для плюсиков).

Что бы попробовать писать код с ИИ нужно сначала уметь писать код в принципе. Это новый тренд что ли рассуждать о том как будет когда смутно понимаешь предмет рассуждения. Сейчас самые умные на мой взгляд это ДипСик и Грок3, но даже они начинаю писать полный бред через две три итерации. Использовать их как справочную систему - это круто, использовать как источник примеров - это круто, попросить сделать очень изолированный алгоритм - да, скорее всего сделают, но код может быть странным, мягко сказать. Последние пару месяцев пишу весь код вместе с ИИ, но это скорее как очень крутая справка и автокоррекция. Чет такое. Мне это, признаюсь, доставляет удовольствие и даже по своему развлекает, давно не испытывал такого при программирование, чем-то похоже на парное программирование, но без второго человека, сложно описать. Однозначно, если у меня забрать теперь эту игрушку мне станет скучнее. Но это не замена, это тула которая ускоряет специалиста. Это все равно что сказать что Visual Assist заменит программиста. ИИ дает примерно тот же эффект, что если бы я писал проект и подглядывал в похожие. Еще достаточно удобно когда например надо в игре сделать что-то похожее на реальный мир, например варку пива, вместо хаотичного чтения разных википедий и книжек, адресно спрашиваю у ИИ он мне в общих чертах объясняет. Потом уже уточняю в справочной литературе, если нужно. Опять же считай справка на стероидах про мир.

И да, галлюцинации это беда.

А как Вы относитесь к тому, что ии успешно решает литкод хард, а Вы, скорее всего, не очень?

ии успешно решает литкод хард

На чём обучен — то и решает, тоже мне сюрприз. Вот пускай он мне порешает проект на 150 мб кода...

Так когда вы (не лично Вы) все свои кодовые базы в него загоните, а кроме того и весь чат вашего недовольства его решения конкретных проблем, и это научится. Научат. Заставят.

Хотите работать эффективнее, уже загоняете прямо сейчас. А потом просто придётся :)

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

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

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

Большинство реальных проблем выбора исчезнет, как только удастся получить способ писать и переписывать код быстро (= дешево), не теряя его функционала. И все это, да, просто продолжение текста хотелок владельца или ответственного за проект. Разумеется, любой сеньор/лид, который является ИО последнего не будет заменен, именно потому, что он совершает выбор. Про всех остальных - уже сложнее.

Я не про такие решения. Попроще.

Например, нужно добавить параметр в функцию. Это решение.

Потом нужно найти места ее вызовов. Это тоже решение. Для этого нужно запустить поиск по файлам проекта. И это решение. Дальше нужно обработать результаты поиска и тоже принять решения.

А все, что умеют эти сети сейчас - это продолжать текст.

Пример простой, но полезным бы я его не назвал. Вот есть функция f(...), есть уже другой код, который опирается, на ее поведение, допустим он нас устраивает. Ничего не мешает добавить в функцию новый дефолтный параметр f(..., newParam=0), и тогда никаких поисков и принятия решений не будет, все будет работать.

Допустим он (другой код) нас не устраивает, причем настолько, что мы к нему даже тесты не писали, и не устраивает, как раз именно из-за того, что мы упустили какую-то существенную часть механики и (в принципе, да) смысла этой функции f.

Первое (и пока единственное что приходит в голову это такая история) Допустим была f(x,y) = sqrt(x2+y2), а нужна была f(x,y,z)=sqrt(x2+y2+z2), так как мы потом поняли, что вообще-то наше пространство трехмерно. Откуда это z брать в остальном коде, без переосмысления исходной задачи ни ИИ ни товарищ сеньор не сообразит без дополнительных вводных. В математическом коде, на этапах проектирования, увы, такое бывает, но обычно означает, что мы вообще не ту задачу решали.

В продуктовом? Но как, почему зачем? Хорошо, допустим была функция LOG(text, severity=LOG_DEBUG) и все джуниорчики решили, что severity это что-то на иностранном, и вообще для продвинутых, и просто дергали LOG(text). Чтобы джуниорчики так больше не делали, лид решил зафорсить этот параметр изменил описание функции на LOG(text, severity), и дал задачку джуниорчикам, чтобы код снова компилился, проставляя severity исходя из здравого смысла между вариантами (DEBUG, WARNING, ERROR, CRITICAL). Один джун везде поставил обратно DEBUG, потому что так раньше работало. Второй решил, что его модуль самый важный в системе, и везде поставил минимум WARNING, но слово CRITICAL его испугало, и от него он отказался. Третий решил, что ERROR = exception, WARNING = тот DEBUG, который для него более важен, а CRITICAL это когда он не знает, как обработать exception в принципе. Лид объяснил почему это не правильно каждому, коммиты не принял, расставил все сам. Прошло три года, тот лид давно уже уехал в Австралию, на его место пришел новый. Посмотрел проект, сказал, "ну вот это и это я понял, тут и тут хорошо, но какой дурак проставлял уровни severity в логировании? Уволить бы его".

Да, примеры из опыта, если что.

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

UPD. А да, рядовой полезный кейс, это dependency injection, с этим более-менее неплохо ИИ справляется. Главное ему так и сказать, что это DI, а не "прокинь мне пожалуйста ссылку на объект вон в ту ветку, ты должен сделать так, чтобы его имплементация не была видна".

Стратегические бизнес-решения — да, их должен принимать тот, кто видит большую картину и несет ответственность. ИИ тут пока даже рядом не стоял.

Технические архитектурные решения — тут ещё сложнее. Хороший архитектор принимает их не монеткой и не броском кубика, а на основе опыта, понимания будущих изменений и компромиссов. Многие решения потом оказываются “ой, не туда пошли”, но это не из-за случайности выбора.

Рутинные ежедневные решения — вот здесь ГИИ уже может помочь. Но даже тут, контекст решает всё.

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

Технические архитектурные решения — тут ещё сложнее. Хороший архитектор принимает их не монеткой и не броском кубика, а на основе опыта, понимания будущих изменений и компромиссов. Многие решения потом оказываются “ой, не туда пошли”, но это не из-за случайности выбора.

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

В большинстве случаев перевешивает требование бизнеса "срочно надо прямо сейчас".
И разработчик делает не правильно, а ASAP, что тянет за собой костыли и тех долг.
В борьбе бизнеса и техников всегда побеждает бизнес, так как он заказчик услуги.

Если рассуждать в рамках ИИ, то в данном контексте он может позволить чуть больше учесть потенциальных проблем.
Опять же, если у того, кто спрашивает хватит квалификации понять, что ему отвечает ИИ.

опять эти нейромантры, та штош такое

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

Примерно так же как и к тому факту что компьютер лучше меня играет в шахматы и го.

Почитайте сколько раз с изобретения компьютера к нам приходила эра ИИ и сколько раз она потому куда-то уходила.

Безусловно каждый приход эры ИИ оставлял после себя много всего, и уже понятно что БЯМ или как говорит автор ГИИ останутся, как остались поисковики, облака, экспертные системы(предыдущий приход ИИ).

Вы сами программировали вместе с ИИ? или только слышали?

Вот хорошо, завтра выходит ПикМик, пишет код в среднем лучше чем человек, а если не пишет? Вот раз и все программа глючит, задача не сделана дальше что? Пойдете в спортлото жаловаться? Или звать обратно только что уволенного Васю программиста. А значит останутся только лучшие, а 90% пойдут подметать улицы, ну хорошо, значит задача попасть в 10% лучших, меня это устраивает, я давно говорю что в профессии очень много лишних людей.

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

А значит останутся только лучшие, а 90% пойдут подметать улицы, ну хорошо, значит задача попасть в 10% лучших, меня это устраивает, я давно говорю что в профессии очень много лишних людей.

А значит каждый из потенциальных 90% будет стремиться попасть в те самые 10% "крутых", делая максимально крутые результаты прямо сейчас (за те же деньги в пределах каждого "сейчас"), а в результате останется все равно 10%. Вот он гротеск вилки.

Скрытый текст
Морти, смотри внимательно, это НЕ ТА сингулярность
Морти, смотри внимательно, это НЕ ТА сингулярность

да не будет конечно. Вы их видели хоть? Этих охотников за айтишными зарплатами. Они и так-то в панику впадают, когда узнают, что тут работать надо. А как придётся бороться, так просто не станут и автоматом отвалятся.

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

Крутыми разработчиками становятся не на первом уровне пирамиды Маслоу-Торвальдса¹, а только когда из Survival выбираются в Entertainment.

———

¹ См. «Just for Fun»

буду сериалы смотреть

Сгенерённые ИИ! /s

Которые заставят и дом и принтер продать и закупить NeoroShitCoinInvestment (с) Чёрное Зеркало

Вставлю свои 5 копеек :)

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

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

Третий фактор - легаси.
Если вы хоть раз окунались в чужой код без коментов и документации, то понимаете, как важно иметь возможность спросить "что это за ерунда" и "почему реализовано именно так".
Думаю, что многие живут не в мире радужных пони, где на все есть качественная документация, а в реальности,
где "документация в голове у разработчика, который уволился 10 лет назад" :)

А калькулятор уже полвека складывает числа быстрее и точнее человека, и что с того?

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

— Два по сорок - рубль сорок! Спички брали?

— Нет!

— С вас два сорок.

Решение задачек с литкода, которые вы приводили в пример выше, тоже будет трудно монетизировать. И что с того?

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

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

Навык решения литкода в большинстве случаев современного коммерческого программирования не показывает ВООБЩЕ НИЧЕГО.

Так и общих стандартов того, что считается навыком коммерческого программирования тоже нет.

Вы не в ту сторону пытаетесь причинно-следственную связь увидеть. Как говаривал капитан Врунгель: «Каждая селёдка — рыба, но не каждая рыба — селёдка».

Разработчик, мнящий себя профессионалом — должен безо всякой подготовки щелкать задачки с литкода, — «прокачка» тут не нужна. Если это не так — перед вами робот-джейсоноукладчик.

Прям с ходу любую задачку уровня hard вам скинуть, и решите за 10 минут на техническом собеседовании без гуглежа?

Сейчас самые умные на мой взгляд это ДипСик и Грок3

Мне, вот, интересен такой момент. Насколько я понимаю, самые востребованные ИИ сейчас – иностранные. Нас усиленно завлекают подсесть на них. Мы, естественно, ведёмся. Рано или поздно наступит момент, что без ИИ станет, как без Интернета – прожить можно будет, но не долго. И что могут сделать «плохие дяди»? Скажут: «Ребята, вы ведёте себя неправильно, мы вводим против вас санкции. Было 28500 санкций против вас, станет 28501. Исправляйтесь, а мы подумаем, снимать их или добавить новые.».

Так что, наверное, уже сейчас надо будет думать о последствиях и готовить контрмеры. Развивать собственные ИИ («Интеллектуальные Игрушки»), искать обходные пути и т.д. и т.п.

Мы, естественно, ведёмся. 

Отучаемся говорить за всю сеть.

В целом ГИГА чат и яндекс гпт не сильно проигрывают. ДипСик выложил файл весов, никто не мешает его локально запустить. Гугл и остальные то же периодически модели показывают. Я могу ошибаться, но самые закрытые модели у самой открытой по названию компании OpenAI.

Спасибо за ваш комментарий — всегда ценю мнение практиков, особенно руководителей разработки 👍

Знаете, тут как с шахматами — разные люди видят одну и ту же доску, но замечают разные комбинации. Мой взгляд сформирован работой с десятками команд и работой в области ИТ уже более 20 лет.

Полностью согласен насчет “копировать без понимания = катастрофа”. Но ГИИ тут не причём. Это всего лишь инструмент. Ноутбуком можно гвозди забивать, но это не будет не очень эффективное его использование😅 Голову человека никто не отменит и конечно не заменит.

По поводу галлюцинаций — абсолютная правда! Для того чтобы работать с глюками и нужен будет человек. Поэтому команды останутся, изменится характер работы и инструменты. И не многовенно, а мой прогноз в перспективе 5 лет.

Кстати, интересно узнать — как именно ваша команда использует ИИ в качестве “второго мнения”? У вас есть какой-то формализованный процесс или это больше на усмотрение каждого разработчика?

P.S. Моя идея не в том, что ИИ заменит разработчиков (это как раз галлюцинация, но со стороны маркетологов ИИ 😉), а в том, что изменятся требуемые навыки — от механического кодинга к более высокоуровневой работе с постановкой задачи, бизнес-логикой и валидацией. Но, возможно, мы говорим об одном и том же, просто с разных сторон?

Формализовать можно только запросы.
Есть ряд подготовленных форм, которые легко гуглятся в интернете.
Из практики лучше всего спрашивать вопросы с бинарным ответом.
Например:
"Предполагаю, что А = Б, я прав? Если нет, то объясни подробно почему?"

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

Можно все, нужно просто спрашивать правильно.
А вот навык правильного спрашивания как раз начинает вытеснять навык гугления.
ИИ - по сути и есть поисковик на стеройдах всего лишь :)

Предполагаю, что А = Б, я прав? Если нет, то объясни подробно почему?

«А мы покупаем или продаём?» ©

Интересный вопрос, только не очень ясно, что вы имели ввиду.
Раскроете вопрос, возможно дам ответ

Я пока вижу, что этот Т9 на стероидах вполне способен заменить agile-коучей прямо сейчас.

ИИ скорее "усилитель интеллекта", чем его замена.

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

уже через год очень много чего изменится,

Скрытый текст

Да кто ж знает

Скрытый текст

(Жизнерадостно:) Ага!

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

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

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

В кульминационный момент она там достигалась историей, "Вы и кушать за меня будете?" - "Агаа!".

Только вот ИИ обратно в ларец уже никто не запихнет.

Любые аналогии условны, как и аналогия с мультиком.

Можно увидеть три формата отношения к ГИИ среди участников

  1. “Вау-подход”: “А нука ГИИ, напиши весь проект!” - получают кучу галлюцинаций, неработающего кода и разочаровываются.

  2. “Нет-подход”: “Это всё бесполезно, видел я уже всё это в другом месте”- не получают никаких преимуществ

  3. “Умный подход”: ГИИ используется для конкретных задач под контролем человека/команды, с направленными промтами, отсеиванием глюков (именно этот подход описан в статье)

    Думаю, ключевое отличие от “двоих из ларца” в том, что хороший ИИ не просто тупо исполняет, а предлагает варианты, которые могут натолкнуть на новые идеи. Как джуниор, который иногда выдает неожиданно полезные мысли.

    Нам нужно оставаться “умнее” в контексте задачи, технической архитектуры и бизнес-требований. Но это не значит, что мы должны знать все детали реализации.

    Время рассудит. Прогноз всегда вероятностен. Человек не оракул и будущее не видит. Любой ответ ГИИ тоже вероятностную природу имеет. Каждый должен относится критически и к прогнозу и к ответам ГИИ. Это нормально.

Пока есть любая зависимость, линейная, или экспоненциальная как в контектсе ГИИ и ИТ-технологий в целом, то можно строить прогнозы. Экспоненциальные тренды - это тоже тренды. Но как только экспонента уйдёт в сингулярность происходит смена прежних закономерностей, и вот за точкой смены трендов конечно начинается чистая фантастика, а не прогноз.

Я еще обучаюсь и обучался с ИИ...Ну как обучался, перестал брэйнштормить и чаще обращаться при каждой трудности или в поисках ошибок в коде...пришлось бросить и начать курс заново (CS50) со следующего года. Сейчас сугубо как просто друг который почитает и покажет на ошибки уже написанного кода, ну или посоветует решение получше, поможет с обьяснениями (explain like a five, весело). Но в рабочем режиме думаю это будет очень неплохим инструментом, напомнить, сделать выбор, исправить баг и прочее. Свыше был уже пример с калькулятором...

Двухнедельные спринты могут уйти в прошлое, когда ГИИ умеет генерировать рабочий код за минуты.

Вообще-то, Agile используется даже в командах, которые работают с no-code решениями. Кроме того, написание кода - это лишь один столбик на доске.

Ага, тоже позабавило, если людей не будет в процессе, ок, не будет 2х недельных спринтов.

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

Был в советское время анекдот "10 студентов заменяют трактор", но вопрос зачем?

Спасибо за комментарий. В тексте я не писал, что Agile уйдёт в прошлое. Речь шла о стандартной принятой практике в большинстве компаний в 2 недельные спринты - это будет долго для нового времени. Изменится принцип "Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale. " Потому что частота выпуска будет стремительно расти, а темпы будут видимо ускоряться начиная с 2026-2027 года.

частота выпуска будет стремительно расти, а темпы будут видимо ускоряться начиная с 2026-2027 года

Вы, как Agile-коуч, должны иметь доступ к метрикам многих проектов. Вы можете посмотреть, насколько увеличилась частота выпусков за два последних года?

Наблюдаю, что частота растёт. Всё верно. Но закономерность роста частоты релизов подобно закону Мура экспоненциальная, не линейная. В начале этот рост экспоненты не так заметен. Я написал в статье, что в перспективе 5 лет движение будет стремительным, несмотря на то, что скорость на старте пока не так сильно ощущаем. Противоречий нет.

А откуда информация про то, что зависимость здесь экспоненциальная? Мне кажется, что скорее наоборот, скоро ИИ проникнет везде, и наступит плато, потому что возможности окажутся исчерпаны. Поясню, почему я так думаю. Дело в том, что чем хуже ты разбираешься в вопросе, тем сильнее тебе может помочь ИИ. Грубо говоря, джун с ChatGPT может работать втрое быстрее, чем без него, а вот сеньор только на 5-10% быстрее. Чем больше в команде неопытных сотрудников, тем больше выигрыш. Но при этом будет расти количество ошибок, которые может исправить только опытный разработчик.

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

Синьёр (настоящий синьёр) с генеративными моделями будет работать вдвое медленнее, чем без них.

Согласен. Но есть и нормальные сценарии использования. Например, задавать вопрос кратко, а полученный ответ использовать как пример или как идею. Итого, минуту тратишь на составление промта, а код в итоге пишешь сам. Ну или форматирование данных, например перегнать в JSON построчный список из описания задачи. Или генерация тестовых данных. Вот прямо сейчас работаю над загрузкой пользователей на сайт из CSV-файла. Создал шапку файла, внёс данные одного пользователя, скопировал в Deepseek, говорю сделай мне такую CSV с героями из Игры престолов, и вот у меня есть адекватный набор данных, а не Qwety Ggggg.

Но тут интересный момент, как считать выгоду. Сам бы я делал эту CSV-шку минут 10. С Deepseek я её сделал за минуту. Значит ли это, что я ускорился в 10 раз? Нет, нет и ещё раз нет. Это значит, что я сэкономил 9 минут времени. А на долгосрочном отрезке времени, если учитывать использование ИИ в других задачах, получится экономия порядка 20 минут в неделю.

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

С каких пор синьёры занимаются джейсоноукладкой?

Или генерация тестовых данных. Вот прямо сейчас работаю над загрузкой пользователей на сайт из CSV-файла.

Это плохие тестовые данные. Хорошие сгенерирует QuickCheck, или его аналог для вашего языка программирования. Потому что завтра к вам придёт пользователь с именем 𝕏, пользователь с шестьюдесятью именами, пользователь вообще без имени, и так далее. Сайт IKEA в Испании требует указать две фамилии (и всех испанцев фамилий две). В результате мне пришлось ехать к ним лично, потому что у меня фамилия одна.

С каких пор синьёры занимаются джейсоноукладкой?

Ну вот представьте ситуацию. Дали сеньору задачу сделать какую-то сложную калькуляцию по формуле из 20 параметров, а результат представить в виде четырёх чисел, карты с наиболее подходящими объектами и списком текстовых рекомендаций. И есть в калькуляции какой-то числовой коэффициент, зависящий от выбора пользователя. Ну например, удельная теплота сгорания разных видов топлива. Все 15 допустимых видов топлива с нужными параметрами приведены в таблице в тексте задачи. Казалось бы, разумно вынести их в конфигурационный файл в формате json. Какие ваши действия? Насколько я понимаю, вы, как настоящий сеньор, создадите отдельную подзадачу: преобразовать вот эту таблицу в json. Но вот беда - задачу некому назначить: на проекте работают только сеньоры, а джунов и мидлов нет. Все джуны заняты на других проектах и полностью загружены. Выход есть: нанять ещё одного джуна, подготовить ему 800 вопросов для технического собеса, по результатам сказать "слабоват, несите следующего".

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

Я попрошу оформить таблицу как таблицу в любом табличном редакторе, сохранить, как CSV и буду парсить CSV (это буквально одна строка), чтобы изменения условий задачи не приводили к рассинхронизации актуальных данных и моего конфига.

Все 15 допустимых видов топлива с нужными параметрами приведены в таблице в тексте задачи.

Тех, кто привёл 15 видов топлива в текст задачи.

А ведь можно скопировать фрагмент текста задачи со списком в нейросеть и сказать "сделай мне из этого CSV", потратив на это одну минуту, вместо того, чтобы ждать непонятно сколько, пока вам прикрепят к задачке табличку. И это абсолютно ничем не отличается от примера с JSON.

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

Не придётся. Мы договоримся, где файл будет лежать, а мой код будет брать его оттуда.

Так, например, поступают все библиотеки для работы с юникодом, написанные адекватными людьми: они парсят файлы консорциума. Так же поступают библиотеки, использующие данные tz_data и многие, многие другие, полагающиеся на статические данные из сторонних источников.

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

А что если приложение предназначено для работы оффлайн? Не беда - будем копировать файл автоматически на этапе компиляции. Чтобы что? Ах да! Вдруг поменяется удельная теплота сгорания каменного угля. Вот только при изменении файла придётся выпускать новый релиз. А как в таком случае отслеживать изменения? Запустить CI, которая по крону долбится каждый день (а может час) в этот файлик, и если файлик поменялся то автоматически создаётся новый релиз.

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

А всё ради чего? Ради того, чтобы один достопочтеннейший сеньор не испачкал свои руки в богомерзком CSV.

Что ж, признаю, что когда вы написали "Синьёр (настоящий синьёр) ", я недооценил, насколько вы настоящий.

PS: а тем временем на стороне заказчика менеджер скажет "Блин, CSV они хотят". Скопирует эту табличку, вставит во всё тот же DeepSeek и попросит сделать CSV.

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

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

Учитывая, что речь идёт о проверке таблицы на 15 строк, думаю 2-3 сторипоинта будет достаточно.

2-3 сторипоинта будет достаточно.

А если оно глюкануло на шестой строке?

Шестой, учитывая шапку, или именно на шестой строке самих данных?

На той, на которой нету этих самых понтов.

Дело не в этом.

Эти данные исходят из третьих рук (заказчик, стейкхолдер, генеральный директор мира) — они отвечают за содержимое.

Если разработчик говорит: «ок, я позову чатжпт и всё забабахаю» — он добровольно берет на себя ответственность за потенциальный взрыв реактора. Это, как минимум, неумно.

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

Я, как настоящий сеньор, пишу макрос в FAR, и за две минуты всё готово.

Вы за две минуты напишете макрос в FAR, который из текста задачи в Jira вычленит нужные данные, преобразует их в нужный формат и сохранит куда-то в кодовую базу?

Стопэ, стопэ, тут только что JSON был — а теперь какой‑то «нужный формат» появился? Сейчас Вы ещё скажете «...который вычленит нужные данные из смазанной картинки, снятой на телефон, на которой запечатлена таблица, нарисованная в ресторане на салфетке».

Для такого фар — колхозное поделие, тут emacs нужен.

Я напомню изначальную постановку вопроса:

например перегнать в JSON построчный список из описания задачи

А это уже вы подрядились сделать это затдве минуты при помощи макроса FAR.

Я наблюдал за изменениями частоты релизов за 10 лет в разных компаниях. Если раньше только обсуждали, что надо чаще релизиться, то последние два года частота выпусков стала расти как факт. Экспоненциальная закономерность - это гипотеза, но пока она подтверждает моё личное наблюдение. Почти всё что связано с информацией и накоплением знаний имеет экспоненциальный тренд. Например, экспоненциален рост числа патентов, производительность процессоров, стоимость хранения 1 бита информации и т.д.

Согласен, что на текущем этапе преимущество только для джунов и может быть мидлов. Однако кроме непосредственно программирования есть ещё в разработке аналитика, документация, автотесты, ci/cd и т.д. - у ребят, кто этим занимается в разы больше рутины, чем у программистов-синьоров.

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

И надо понимать, что инструменты развиваются. Что будет полезным из ГИИ синьорам через 2-3 года мы увидим. Прогноз всегда вероятностен и точно не линеен.

Например, экспоненциален рост […] производительность процессоров

Скоро в вашей вселенной наступит 2005 год и производительность процессоров упрётся в квантовомеханические эффекты и выйдет на плато.

Любая экспонента упирается в сингулярность, за которой следует смена закономерностей.

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

И я так понимаю, у этой гипотезы есть какое-то обоснование?

Конечно. Интернет закончился. Буквально все, кто не сосет прямо сейчас очередной раунд из инвесторов, твердят это хором.

Так, будто не инвесторы выбирают, куда переливать капитал.

Я не смог понять, какой смысл заключается в этой фразе.

Инвесторы уже выбирали доткомы 25 лет назад. Напомнить, чем закончилось?

А чем закончилось, ну то есть что из всей истории Вам кажется тут самым важным?

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

В общем, наверное, я ничего не понял в Вашей фразе "Интернет кончился".

я ничего не понял в Вашей фразе «Интернет кончился»

Этот мем мимоходом бросил Альтман (видимо, с похмелья), но потом быстро переобулся и теперь эти обсуждения — больше удел ученых, далеких от маркетинга.

«Интернет кончился» — буквально означает: «мы всё, что можно, — уже скормили сетям, учить их больше не на чём».

На пользовательских историях научат. Интернет-то он изрядно тупой.

Откуда у вас такие данные, что генеративные модели “уперлись и вышли на плато”, особенно в контексте генерации кода?

Анализ статей с показателями показывают совсем другую картину.

Вот конкретные цифры по бенчмарку HumanEval (% успешно решенных задач кодирования):  от ~30% до более 90% за три года. Это не экспонента? На других бенчмарках тренд аналогичный.
Можно посмотреть на ежемесячные обновления бенчмарков на HuggingFace Open LLM Leaderboard или McKinsey Technology Trends Outlook. Пока выхода на плато авторитетные источники не выдают.

Это бенчмарки по тестовому набору данных, алё.

Всё жду исторИИ успеха о проектах хоть чуть выше плинтуса.

Это большой соблазн всё "написать" и ни..я не понять.

С проектами чуть выше плинтуса они слона ИИ не продадут.

Попробуйте посмотреть на ситуацию через замену ИИ на менее конкретную и более нейтральную для восприятия аббревиатуру ПО.

Появился новый тип ПО. ЕГо продвигают бигтехи, у него есть евангелисты. Этому ПО нашли применение в т.ч. и в разработке. Это ПО помогает улучшать уже написанный код или даже писать новый код с нуля. Разработчики и архитекторы изучают это ПО, ищут возможности его внедрения. При всей пользе и позитивных прогнозах о будущем этого ПО, на сегодня также очевидны и сложности и проблемы в его использовании. Это ПО, какое оно есть на сегодня, не стало серебряной пулей для решения любых задач.

Как вам? Конкретно я уже не улавливаю хайп между строк. Не переживаю за будущее человечества. Не планирую увольнять всех разработчиков.

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

Вы правы, если посмотреть так, то многое встает на свои места. Мы действительно проходим знакомый путь: новый инструмент → хайп → завышенные ожидания → разочарование → продуктивное использование. Прямо по классической кривой Гартнера. С практической точки зрения, полностью поддерживаю ваш здравый подход.

Помню на одном митапе в 2010 году говорили, как облачные технологии должны были “уничтожить” профессию системного администратора в компаниях. А по факту просто изменили требуемые навыки.

Есть небольшое отличие от других ПО конечно, современные ГИИ-инструменты иногда выдают такое, что даже их создатели удивляются  :-)

Вы сами используете ГИИ-инструменты в работе? 

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

Стал ли ИИ на сегодня для меня панацей? Нет.

Боюсь ли я потерять из-за него работу? Нет.

Но жду ли я роста значимости этого инструмента? Да.

У меня лично включен фильтр на признаки ИИ, и я возвращаю письма, на которых он положительно сработал, — авторам — не читая.

текстам, имеющим признаки создания при помощи ИИ

там не только признаки но и качество плохое

Мое мелкое, никому не нужное имхо. В статье расписано, как круто и насколько быстрее будут "выдавать на гора" решения, код, внедрения... Но никто ниразу не задумывается, а сможет ли человек со своей физиологией и психикой ускориться настолько, чтобы выдавать эти "на гора". У человека есть предел по времени сосредоточения на задаче, скорости обработки информации. ИИ хорош, как вспомогательный инструмент при принятии решений, но через какое то время гонка на скорость приведет к тому, что люди будут не просто выгорать, а становиться просто недееспособными. Это при том условии, если мы сохраним стремление к БЫСТРЕЕ, БОЛЬШЕ, ЛУЧШЕ. Уже сейчас огромное количество людей страдают выгоранием и депрессией. Попытка "выдавить с кошечки еще капельку" приведет общество к массовым суицидам.

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

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

Кал Ньюпорт в книге “Digital Minimalism” писал: “Технологии должны служить нашим глубинным ценностям, а не превращать нас в рабов эффективности. Когда мы оптимизируем только скорость и объем, мы жертвуем глубиной и качеством — как работы, так и жизни”.

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

Вы как думаете, возможен ли такой подход в реальной корпоративной среде? Или всё же культура “быстрее, больше, лучше, стресс, ещё больше и лучше и ещё быстрее” перевесит человеческие потребности? Дело же не в ГИИ, а в нас, людях. У ИИ нет целей, желаний и эмоций, нет ничего человеческого.

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

К сожалению, но в текущих реалиях выигрывают компании, в которых царит "людоедская" корпоративная культура. Соответственно, как только появляется какой либо инструмент, способный сменить ряд механизмов/винтиков на более дешевый аналог, замена следует незамедлительно. Это уже абсолютно все прочувствовали на собственном опыте. Попробуйте сейчас дозвониться до живого сотрудника техподдержки оператора связи или банка. 99% вы попадаете на робота. И конкурировать с роботами на простых задачах не получится. Роботу не нужен сон, отпуск или больничный. 1000 роботов будет обслуживать высококлассный специалист по роботам, но он, условно, будет получать в 10 раз меньше всех людей, которых заменили боты.

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

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

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

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

если автоматизация успешная и привела к удешевлению

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

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

А про приколы от ИИ можно рассказывать долго. Например, я тут, на днях, общался с французской «интеллектуальной игрушкой», на тему французского языка. Так вот, она не могла мне внятно, с первой попытки, ответить на простые вопросы: «Сколько букв и звуков во французском языке?». И даже когда я просил перечислить буквенные и звуковые символы французского алфавита, ИИ подсчитывал их неверно. Потом, правда, дико извинялся, когда я указывал на ошибки.

А так вопрос очень интересен, правильного ответа на него не дает никто, ни сами французы, ни преподаватели французского. Точнее, ответы у всех разные. Скажем, количество букв алфавита для стандартного французского языка, называют в пределах от 26, до 44. А количество фонетических звуков от 36 до 39, не считая диалектов. С буквами у них путаница, считать ли символы с диакритическими знаками, отдельными символами либо тождественными знакам латинского алфавита. Чаще всего, они их не различают, т.е., акцентов и лигатур, у французов, как бы, не существует, вплоть, то игнорирования их в процессах сортировки. А там, где о них говорят, то никак не могут определиться, какие гласные, с какими акцентами, у них допустимы. И только циркуляр Министерства Юстиции Франции, от 2014 года, однозначно определяет количество допустимых, во французском языке, гласных с диакритическими знаками (включая графему c-cédille) и лигатур. Всего таких символов, с акцентами – 16 плюс две лигатуры, что в сумме с 26-тью буквами латинского алфавита дает число 44. Но, кто про это знает? Из 16-ти допустимых акцентов, вам, чаще всего, во всех источниках, включая Ютуб, назовут 12, максимум 13. Та же песня с количеством фонетических знаков в стандартном (в Париже) фонетическом алфавите. Я долго пытал французский ИИ, который называл мне цифру 36, хотя, но с трудом, выдавал список для 39 допустимых фонетических символов. Во всех же учебниках французского пишут – 36 звуков, и только один источник на Ютубе, назвал правильное количество – 39. Кстати, это хороший тест для наших преподавателей французского… :) . Причем, «стратегическая неопределенность», как удачно выразился «нонешний» французский Президент, относится и к другим аспектам французского языка. Например, все французы упорно делают вид, что у них не существует «шва»-звука, хотя они все используют его. И много чего еще. В общем, официально «устаканить» свой любимый язык он не могут до сих пор.

Интересно что подобные статьи обычно и пишут не разработчики а кто угодно,кто видимо мечтает заменить собой разработчика без затраты времени на обучение и годы на ошибки.

Забавно, что вы сразу записали меня в “кого угодно, только не разработчика”. А я начинал программировать ещё школьником на Паскале на древнем УКНЦ МС-511 (кто помнит эти чудо-машины советской эпохи — привет из прошлого!). Работал программистом с 2000 года, со второго курса, и набил шишек в реальных проектах почти за 10 лет практики. Я могу ручками вести разработку через VIM, настроить ci/cd, использую docker, понимаю в архитектуре и т.д.

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

В статье (которую, похоже, вы не дочитали) я как раз и пишу про ДОПОЛНЕНИЕ возможностей разработчика с помощью ГИИ, а не про замену людей. Это принципиально разные вещи.

Самолёт летает лучше любого человека и даже любой птицы, но мы же не говорим, что “самолёты заменят людей”. Мы говорим, что самолёты расширили наши возможности передвижения.

Так и с ГИИ в разработке — это инструмент, который берёт на себя часть рутины и помогает быстрее решать знакомые задачи. Дальше в перспективе 5 лет будет интереснее — это главная мысль. А творческое мышление, понимание бизнес-контекста, архитектурные решения — это всё остаётся за человеком.

Зачем спорить с тем, чего я не писал? Например, в этой дискуссии с первого поста начинается разговор о “замене разработчиков” и другими словами излагается то же самое, что я написал, хотя в статье речь о совершенно другом - о дополнении и новых возможностях? Или Agile-coach — это точно никак не программист и не читая сразу минус в карму, не читая?

Кстати, а вы сами пробовали использовать ГИИ в своей работе, использовали Cursor с подпиской или дополнения к IDE? Было бы интересно узнать ваш опыт, без предвзятости.

Фантазия на тему что сделал ИИ за ночь конечно интересная, но к реальности имеет мало отношения.

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

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

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

У меня прогноз на следующие 5 лет, который я делаю на основе статей по текущим трендам. Прогноз вероятностен и может быть даже футуристичен, может не сбыться. Однако так выглядят тренды.

По моим наблюдениям ИИ работает хорошо только с теми данными на которых он обучался.

Bash скрипты выходят средние.

Скрипты под микротик плохо.

Postgres запросы плохо.

Нашёл одно отличное применение ИИ - создание регулярных выражений

Интересно наблюдать, как дискуссия идет на уровне "заменит/не заменит".

Реальная трансформация идет не в направлении "сокращения разработчиков", а в изменении характера работы: от синтаксиса к семантике, от написания рутинного кода к валидации, от "как" к "что" и "зачем". ИИ берет на себя рутину генерации кода, а разработчик все больше становится тем, кто формулирует задачу, проверяет результат и интегрирует его в общую систему.

Это не вопрос "кого заменят", а вопрос "как изменятся роли и требуемые навыки". Сокращаться будут не столько рабочие места, сколько потребность в специалистах, не желающих адаптироваться к новым инструментам.

разработчик все больше становится тем, кто формулирует задачу, проверяет результат и интегрирует его в общую систему

На задачах, чуть сложнее джейсоноукладки, это не работает.

как будто шпалы укладывать

На задачах, чуть сложнее джейсоноукладки, это не работает.

Какие конкретно модели ИИ вы использовали в работе?
С какими типами задач пробовали работать?

Каждой более-менее заметной новой модели я скармливаю текущую задачу по развитию одной из своих опенсорс-библиотек. Текущую — это первую из issues, над которой я прямо сейчас работаю.

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

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

Но это не значит, что ИИ неэффективен в разработке. Просто нужен правильный подход:
1. Правильная модель: Разные модели, разные стеки, разные результаты.
2. Правильная декомпозиция: Если задачу нельзя чётко объяснить в 2-3 абзацах, она слишком велика для одного запроса.
3. Правильный контекст: Не просто "напиши мне X", а "вот существующий код [код], используемые паттерны [описание], создай компонент X, который будет интегрироваться в Y с учетом Z ограничений". Контекст определяет 80% качества результата.

А за пивом ему сбегать не нужно?

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

Я прислушиваюсь к мнению «ИИ полезен» только от тех людей, которые покажут мне нарисованную чайку с гаечным ключом в лапе.

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

Вот только эта «чайка» не нарисованная, а отрендеренная, и ключ очевидно бутафорский (при такой длине — там рычаг совершенно никакой).

Лучше сделайте мне фотореалистичного слона, делающего стойку на своём хоботе.

4 Правильные итерации: Качество результата пропорционально качеству вашего диалога с ИИ.

А пальца — всё равно четыре...

5 Правильные ожидания: ИИ в разработке — не идеально, но практически полезно при правильном подходе.

Признаю́: ваша итерация ④ — лучшее, и максимально близкое, из того, что мне доводилось видеть. Спасибо за потраченное время и усилия, я ценю это.

Дьявол, к сожалению, в деталях: в данном случае вы, как оператор, за долю секунды решили задачу в уме (потому что человеческий мозг щелкает такие выходы из плоскости «уже виденного» — на раз), — а потом просто подводили (кого кстати? это грок?) сеть к известному вам заранее результату.

Сложная задача в разработке кардинально отличается от этого: чаще всего я просто не знаю, как правильно, пока не начну писать код. Напишу строк сто, выпью кофе, перекурю… — Вернусь к компьютеру, скривлюсь в гримасе отвращения — и выброшу в мусор. И так три, пять, десять раз.

Когда же мне станет понятно, как должен выглядет конечный результат — сам код появится со скоростью печати.

Думаю, мир достаточно велик для разных подходов.

вы, как оператор, за долю секунды решили задачу в уме — а потом просто подводили сеть к известному вам заранее результату

Здесь есть важный нюанс.

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

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

В разработке с ИИ я часто не знаю конечного результата — я знаю лишь направление и примерные критерии качества, а затем через диалог с моделью постепенно приближаюсь к решению.

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

Я сгенерил уже десяток картинок, каждая из которых выглядит как кринж, потому что никакие законы физики или физиологии не соблюдаются. Но можно все равно херак херак и в продакшн (NB заказчик сам виноват).

"Чайка с гаечным ключом" — как метафора для нестандартных задач программирования. Суть не в том, может ли чайка физически удержать ключ, а в том, можно ли с помощью методичного подхода (правильная модель, декомпозиция, контекст, итерации и ожидания) получить от ИИ результат в задаче, которая кажется невыполнимой?

Именно. Наступила неделя чаек с ключом на 16, карма некоторых персонажей удвоилась.

Спасибо за "чайку с ключом" — это действительно идеальная метафора ограничений и возможностей ИИ. Очень наглядно!

Я действительно рад, что мы нашли общий язык.

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

«Единственный способ определить границы возможного — это выйти за них в невозможное» ©

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

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

Ближе к третьему десятку ретраев запроса "фотореалистично: чайка держит гаечный ключ лапой" я получил вариант, который заставил меня задуматься.

Скрытый текст

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

Это неплохо, правда, мне и такого добиться не удавалось.

Но код-ревью все-таки пока не пройдет :)

И так мы делаем полный круг

Забавный тренд на то, как Agile-специалисты, обладая «обширными» знаниями в ЯП и основных парадигмах программирования, да и вообще во всем шарят, ведь Agile – это круто.

Но на мой взгляд они упускают главное, любая ИИшка, ГИИшка – это всего лишь инструмент. Не умея им пользоваться и, что самое главное, НЕ ПОНИМАЯ, а просто зная, что он делает, сильно полезным специалистом ты будешь считать, а что самое главное будешь ли ты считать себя таковым?

Никто не забирает фактическую важность ИИшек в современное время, но ведь это просто инструмент, помните об этом.

И понимайте, а не знайте!

Sign up to leave a comment.

Articles