1700 строк кода

Я все еще пишу сервис, с использованием AI. Написано 1700 строк.

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

Главное, что меня волнует - мне кажется, что это какое-то читерство. Я не уделяю внимание важным вещам, а просто “прошу кого-то” выполнить за меня мою работу. Но если углубиться, в чем же разница?
Предположим, мне нужно интегрироваться с внешним сервисом. Мои действия?

1. Найти документацию внешнего сервиса
2. Изучить API или SDK, если они предоставляют его
3. Написать код интеграции.
4. Протестировать и принять решение о готовности

Особенно много времени я трачу на 1 и 2 пункты. В случае же применения AI, у меня получается:

1. Сформулировать вопрос и ограничения известные мне
2. Получить код, прочитать его. Убедиться, что код делает то, что я хочу
3. Встроить код в мое решение
4. Протестировать и принять решение о готовности

Конечный результат - одинаковый. Но в первом случае я трачу много времени на первые 2 пункта. Во втором, я получаю ответ за 5 минут.

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

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

Как Разработчики используют Copilot

Кажется, что я упустил то, как AI активно внедряется в работу разработчика. Ну или, разработчикам стыдно признаться, что они используют Copilot активно для своей работы :)

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

Если посмотреть на работу инженера (вот исследования раз и два про рабочий день разработчика), то фактически разработчик кодит до 20% рабочего времени (1.5-3.5 часа в день).

А все остальное время - он занимается работой, но не кодингом (встречи, чтение документации, чинит баги, вручную сидит и делает что-то). И задача AI - пусть даже на 10% увеличить эффективность разработчика. То есть, дать инструмент, чтобы те самые 20% рабочего времени выдавали больше результатов.

Так вот, Github Copilot вокруг меня, по статистике, используется 70% инженеров. Но никто не говорит об этом!

Я спросил явно, какие сценарии применения у инженеров, получились достаточно интересные:

• При работе с большой кодовой базой

  Расскажи, что тестирует вот этот тест на 1000 строк? Какие функции он проверяет?

  Вот эта функция, где она используется в моей кодовой базе? Как она тестируется?

  Я написал вот эту функцию, она выполняет вот такую задачу. Как я могу улучшить эту функцию?

• Работа с неизвестным языком программирования (в котором инженер неопытный)

  Я работал с chef 3 года назад, и часть забыл, поэтому я спрашиваю - объясни мне, что эта часть кода выполняет?

  Мы много стали писать на C#, но я только переключаюсь на этот язык, поэтому я прошу Copilot написать мне ту или иную функцию на C#. Или написать тесты к этой функции, которые я проверяю и принимаю

  Вместо поиска документации по множеству источников, я спрашиваю у Copilot, он мне дает ссылки на них.

При этом, часть инженеров испытывают проблемы:

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

В целом, я рад, что разработчики применяют этот инструмент. Еще идет период поиска границ применимости этого инструмента. Об этом я расскажу завтра :)

А что с рисками использования AI разработчиком?

Кажется, что тут много чего очевидного, особенно учитывая раздел выше.

Это подтверждается моим опытом, в том числе:

1. Возникает стойкое желание - хотеть большего. Вот написал вам AI метод, дальше класс. Дальше вы просите написать его логику сложную, по вашим требованиям. И вроде бы, выглядит-то все прилично, красиво, организованно. И это гасит беспокойство по поводу того, что в отдельной строке тот или иной параметр не был учтен, что может сказаться на работе приложения при нагрузке
2. Когда код, написанный AI отправляется на ревью разработчиком уровня Senior, то это вносит определенный диссонанс. Код вроде стройный, ну и разработчику доверяют - он же Senior, фигню не напишет. А код писал не он, а AI. Ревьюер же этого не видит и в результате может закрыть глаза на какие-то неточности, шероховатости в коде. Ведь Senior код писал!
3. Снижение планки требований. Вот вам сгенерировал класс AI. И в целом, класс во многом отличен. Не соблюдены требования, которые вы бы применили (переменные названы иначе, не как snake_case). Мелочь, может и не нужно переписать? А в результате, с каждым таким разом увеличивается когнитивная сложность кода
4. Обучения не происходит. Потому что задача написать код (решить задачу), а не обучиться. Я, правда, думаю, что обучение уже остановилось тогда, когда стали брать готовые куски кода со stackoverflow, не вчитываясь в содержимое кода.
5. Когда весь код написан AI (это как раз мой эксперимент), то когда что-то перестает ломаться - ты уже не понимаешь где и почему сломалось. Много кода написано не тобой, в голове принятые решения не задерживаются. В результате код становится хрупким. Что-то изменил в отдельной части решения, сломалось что-то еще. Это выливается в то, что нужно много времени тратить на дебаг и поиск причин, почему не работает. В целом же, это нормально для огромной кодовой базы, где одновременно пишут десятки разработчиков. Но не для кодовой базы в 1700 строк. Вся модель решения с запасом укладывается в голове.
6. А еще я попробовал зарефакторинг код… Изначально у меня был код-лапша. Далее я попросил - а сделай красиво, пожалуйста, разложи по отдельным классам, все это собери аккуратно и запусти. AI сделал. Но потерял значимые куски кода, которые потом пришлось отыскивать по истории комитов; искусственно уменьшать контекст, чтобы не было подобных потерь. И здесь уже эффективность применения AI снижается для команды разработки.

Эти риски у меня не уменьшились с момента написания статьи про использование AI в Менеджменте. Нужно правильно использовать инcтрумент. У него есть границы применимости.