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

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