Comments 14
По сути вы предлагаете подход к разработке с бесконтрольным накоплением технического долга. Где каждая следующая итерация разработки оказывается дороже предыдущей. И эта стоимость растёт не линейно, а по экспоненте. Для проектов с коротким жизненным циклом (20-30) итераций такой подход может сработать. А в проектах с длинным жизненным циклом вы быстро придёте к неоправданно высокой стоимости следующей итерации.
Я уже знаю, чем вы возразите. Перегенерировать с нуля! И для примера приведёте с десяток хайповых статей, где LLM нагенерировал миллион строк кода. Но есть нюанс. Между кодовой базой с миллионом строк и реально работающим проектом лежит пропасть. И генерировать вы будете не по вылизанной кодовой базе, а по проекту с гигантским техническим долгом. С частично утраченным контекстом разработки. И, по сути, во время перегенерации вы пройдёте тот же цикл с накоплением технического долга, только очень быстро. Сгенерировали. Нашли баг. Поправили. Вылезло еще 2 бага. Снова поправили. Вылезло 4 бага, причем один старый. По сути так вы совершите те же 200-300 итераций, только очень быстро. И ваш новый проект очень быстро придёт в нерабочее состояние.
PS
Индустрия уже проходила этот этап, только в менее комической форме. Когда компании нанимали толпы джунов, в надежде задавить техническую сложность количеством исполнителей. И этот подход так же оказался нерабочим - из за бесконтрольного накопления технического долга.
Вот хорошая статья в тему.
Для контроля кода есть метрики. Если ты можешь определить как правильно проверять код, то и ИИ может - передай в инструкция свои знания и агент будет работать как надо (после тестирования и то не всегда, но для этого есть тесты и всегда можно поправить и откатить)
У меня агент перед итерацией пишет критерии успеха задачи, потом по ним пишет тесты, потом по этим тестам в режиме луп делает пока все не станет зеленым и сразу после итераций агент запускает тесты на any, сушит код, если файл больше 600 строк - рефакторит. Причём я его даже не запускаю напрямую - его запускает другой агент, который отвечает за распределение задач. То есть я уже на два уровня от написания кода
Если ты можешь определить как правильно проверять код, то и ИИ может - передай в инструкция свои знания и агент будет работать как надо
Вы ведь инструкции пишете на русском или английском языке, правильно? А человеческий язык передаёт информацию недетерменированным способом - одно и то же высказывание разные люди/агенты могут понять по разному. Более того, один и тот же агент в разные моменты времени может понять одну и ту же инструкцию по разному.
А по вашим недетерменированным инструкциям генерируется и код и тесты. Причём, судя по описанию, ни код ни тесты вы не ревьюете. Соответственно у вас нет абсолютно никаких гарантий в коррекности сгенерированного вами кода. По сути вы этот код не контроллируете. Значит вы им не владеете - т.е. не можете гарантировать корректность кода в данный момент, не можете гарантировать исправление ошибок, не можете гарантировать корректность внесения изменений. А раз вы этим кодом не владеете, то ценность вашей деятельности для бизнеса равна нулю.
Но, в чём я с вами согласен, так это в том, что профессия реально изменится. Она станет менее массовой. Один техлид с командой агентов вполне заменит традиционную команду разработки. Вход в профессию усложнится. С улицы с курсов в неё уже не войдёшь. Только из топовых Вузов в крупные холдинги по программе стажировки. Хорошо это или плохо - даже не знаю.
Не уверен, что это обязательно сведётся именно к «только топовые вузы». Но то, что вход станет менее прямым, а требования к уровню мышления вырастут, мне тоже кажется вероятным. И ещё один важный момент. С появления первых версий агентных систем прошёл всего примерно год, так что принимать их нынешнее состояние за предел развития точно рано.
Для обучаемой системы важно одно - структура обратной связи.
Сильная фраза, но конечные пользователи LLM-ки не дообучают, промпт - это не дообучение.
И вот здесь у разработки есть неудобное свойство, о котором индустрия предпочитает не думать: внутри рабочего пространства она куда более детерминирована, чем кажется.
Берётся конкретное состояние репозитория. Конкретный набор ограничений. Дальше действия дают вполне осязаемые последствия. Ошибка воспроизводится или ушла.
Нейронка автора забыла упомянуть очень важное ограничение: при изменении не добавились новые ошибки. Сильно усложняет задачу, потому что в такой формулировке она перестаёт быть детерминированной. Поскольку требования для задачи задаёт кожаный, то решить проблему можно так: нейронка должна (не глюкнув, это сложно) описать изменившееся поведение системы настолько глобально, насколько вляют изменения, и кожаный должен проревьюить его (тоже не глюкнув).
И вот в чём проблема: чем лучше инженерный процесс поддаётся измерению, тем хуже он защищает ручную работу внутри себя
Да с чего бы?
да, промпт не равен обучению; мой тезис в том, что формальная обратная связь делает всё большую часть цикла реализации пригодной для автоматизации.
Этот тезис нуждается в обосновании.
Давайте я дам тупой пример: есть тест, который запускает всю программу, и выдаёт булевский результат: работает или не работает. Автоматизируйте исправление. Со звёздочкой: нужно не сломать то, что до исправления работало.
Окей, давайте по условию. Булевый тест плюс регрессионное ограничение это уже два сигнала, достаточно, чтобы агент крутил цикл. Проблема в том, что задача слишком простая, чтобы быть показательной. Интересный вопрос начинается там, где сигналов много и они противоречат друг другу. Но именно на регрессии агент с CI в цикле надёжнее человека, он не срезает углы.
О нет, нас уволят!
Проходили уже, много-много-много раз. Читайте классическую статью There is no silver bullet - написанная в годы, когда многие сегодня живущие программисты еще даже в проекте не были, а проблемы, оказывается, те же самые и пути поиска их решения не поменялись.
Ключевое, что нужно понимать - программирование - это не про написание кода, не про тесты и практики devops, это - про создание сложных систем, про умение сделать так, чтобы оно крутилось и работало, по возможности, правильно. Инструментарий меняется, эволюционирует - это факт, но суть решаемых задач от этого проще не становится. LLM - это просто еще один слой абстракции, как раньше C вытеснил ассемблер, а его, в свою очередь, C++, Java и прочие последователи.
Скептики скажут, что надо писать код по старинке - самому. И будут правы. Массовое использование нейронок для написания кода уже где-то тут, но пока что это всего лишь исполнительный джун, который лепит своё приложение из всего, что нашел на стековерфлоу
Разработчики смотрят не туда: AI меняет саму механику разработки