Обновить

Разработчики смотрят не туда: AI меняет саму механику разработки

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели5.7K
Всего голосов 10: ↑7 и ↓3+5
Комментарии16

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

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

Я уже знаю, чем вы возразите. Перегенерировать с нуля! И для примера приведёте с десяток хайповых статей, где LLM нагенерировал миллион строк кода. Но есть нюанс. Между кодовой базой с миллионом строк и реально работающим проектом лежит пропасть. И генерировать вы будете не по вылизанной кодовой базе, а по проекту с гигантским техническим долгом. С частично утраченным контекстом разработки. И, по сути, во время перегенерации вы пройдёте тот же цикл с накоплением технического долга, только очень быстро. Сгенерировали. Нашли баг. Поправили. Вылезло еще 2 бага. Снова поправили. Вылезло 4 бага, причем один старый. По сути так вы совершите те же 200-300 итераций, только очень быстро. И ваш новый проект очень быстро придёт в нерабочее состояние.

PS

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

Вот хорошая статья в тему.

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

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

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

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

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

Мне кажется вы немного перегнули.

Главный product owner тоже не контролирует качество кода и точность реализации. Его волнует конечный результат, если он ок, значит хорошо. Допустим он может теперь добиться этого без разработчиков. Ценность высокая.

Ну и 'гарантировать' к сожалению никто не может ни с ai ни без ai 🙂

Однако в будущем ai будет вероятно намного стабильнее лучшего программиста сегодня.

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

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

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

Для обучаемой системы важно одно - структура обратной связи.

Сильная фраза, но конечные пользователи LLM-ки не дообучают, промпт - это не дообучение.

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

Берётся конкретное состояние репозитория. Конкретный набор ограничений. Дальше действия дают вполне осязаемые последствия. Ошибка воспроизводится или ушла.

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

И вот в чём проблема: чем лучше инженерный процесс поддаётся измерению, тем хуже он защищает ручную работу внутри себя

Да с чего бы?

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

Этот тезис нуждается в обосновании.

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

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

Проходили уже, много-много-много раз. Читайте классическую статью There is no silver bullet - написанная в годы, когда многие сегодня живущие программисты еще даже в проекте не были, а проблемы, оказывается, те же самые и пути поиска их решения не поменялись.
Ключевое, что нужно понимать - программирование - это не про написание кода, не про тесты и практики devops, это - про создание сложных систем, про умение сделать так, чтобы оно крутилось и работало, по возможности, правильно. Инструментарий меняется, эволюционирует - это факт, но суть решаемых задач от этого проще не становится. LLM - это просто еще один слой абстракции, как раньше C вытеснил ассемблер, а его, в свою очередь, C++, Java и прочие последователи.

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

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

Задача: создать сервис поиска по лицу. На входе фото, где могут быть или не быть люди с лицами, в произвольных позах и количествах. На выходе векторы в elastic, по которым можно поискать похожий. Из требований - низкая точность, но должно выполняться на cpu и побыстрее. Ь е просто взять и шлёпнуть код из первой попавшейся репки нельзя, он тупо будет тормозить.

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

Автор кода (т е я) почти ничего не знает о "стейт-оф-зе-арт" моделях, нужных для задачи и очень мало знает о машинном обучении, но по крайней мере знает, что нужны метрики. Использовался не агент, обычная LLM. И как оказалось, к счастью. Ошибок и несоответствий было столько, что с описанным агентым подходом "попробовал, откатил, новая попытка" оно бы никогда не закончилось! Потому что некоторые решения он просто не в состоянии сам предложить. Будет ходить по кругу... И это одна из больших моделей, где каждый запрос на кластере дорогущих видеокарт обрабатывается... Это помимо всяких мелочей (например попытка использовать модель, которой по факту нет, или модель под коммерческой лицензией, не сказав об этом ничего...) Про "грязный" код я молчу - там где можно выделить метод, он его просто дублирует. В процессе "забыл" конвертацию цвета bgr2rgb, это выяснилось только уже на этапе тестирования и только потому, что было в коде другое место, где он её не забыл. Иначе искать мне неделями что не так, потому что я никогда не использовал opencv и понятия не имел, что там BGR, а не RGB.

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

А, да, каждый тестовый прогон по валидационному датасету занимает около 10 минут. Поэтому цикл "вносим правку, проверяем" далеко не моментальный. Это не веб-формочку в vs code кодить, когда результат сразу на экране...

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

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

Публикации