Роль ИИ в разработке

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

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

Наставник знает, о чём ты ещё не спросил

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

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

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

С этим я не спорю. Но сравнивать стоит с хорошим наставником. Плохой преподаватель тоже может просто решить задачу за ученика. Человек получит правильный ответ и ничего не поймёт. Присутствие живого человека само по себе ещё не делает обучение полезным.

Готовое решение не заменяет попытку

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

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

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

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

Для начинающего фронтендера по-прежнему важны HTML, CSS и JavaScript. Нужно понимать, как получается интерфейс и что происходит в браузере. TypeScript помогает работать с контрактами, но знание одного фреймворка не заменяет эту основу. Без неё трудно даже сформулировать, чего ты хочешь от нейронки, а потом проверить, действительно ли она это сделала.

Читать код придётся внимательнее

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

Этот навык и раньше был важен, а теперь становится одним из основных. Объём кода, который разработчик получает на проверку, растёт. Можно быстрее написать функцию, но всё равно нужно понять, как она встраивается в систему и что изменится после её появления.

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

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

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

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

Собеседование начинается с обсуждения решения

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

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

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

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

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

Объяснить задачу тоже нужно уметь

Фразу «я бы сам быстрее написал» легко понять. У тебя есть представление о результате, а нейронка после нескольких попыток приносит что-то не то. Хочется закрыть её и сделать руками.

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

С нейронкой стоит разбирать, где разошлись ожидания и результат. Достаточно ли было контекста, понятны ли ограничения? Иногда полезно прямо спросить, почему она приняла такое решение. Затем поправить инструкции, чтобы не объяснять одно и то же при следующем обращении.

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

Поэтому выбор между техническим развитием и продуктовыми навыками мне кажется странным. Они всё больше нужны вместе. Чтобы ставить задачи, полезно понимать продукт; чтобы принимать результат, нужно инженерное мышление. Умение объяснить желаемое и договориться о критериях постепенно становится частью повседневной технической работы.

Эксперимент стал дешевле

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

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

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

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

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

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

Процент сгенерированного кода мало что объясняет

Желание компании делать больше с меньшими затратами мне понятно. Если инструмент помогает, странно вовсе не рассматривать его использование. Но отчёт о том, сколько процентов кода написано нейронкой, ещё не говорит, насколько лучше стал продукт.

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

Здесь мы с Серёжей расходились в акцентах. Я говорил прежде всего о стремлении бизнеса повысить производительность. Он возражал против представления, что эффективность обязательно означает массовость и рост объёмов. Небольшая прибыльная компания тоже может быть успешной много лет. В пример он приводил 37signals. Не всем нужно становиться огромной корпорацией.

Любить работу необязательно одинаково

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

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

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

Я знал, как обходить ошибки Internet Explorer 6, 7, 8 и 9 и заставлять несовместимые браузеры показывать одну страницу. В какой-то момент весь этот пласт знаний пришлось выбросить. Было немного обидно. Ещё пытаешься рассказывать новичкам, как тебе было трудно, а им это уже совершенно не нужно.

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