Что заберет у нас ИИ
В сети разгораются нешуточные дискуссии на тему замены разработчиков искусственным интеллектом.
Какой-то сын маминой подруги пишет, как его харнесс (если что, это приличное слово, погуглите) помогает ему делать всю свою работу за два часа, а остальное время пить смузи на пляже. Другой отвечает, что единственное, что создает ИИ — боль, техдолг и проблемы. Пока обыватели пытаются разобраться, пора ли выкинуть на помойку свое резюме программиста и переучиваться на электросварщика, самые умные изучают историю.
Отчетливые попытки заменить человека на машину были еще в середине прошлого века. Во время Второй Мировой войны Норберт Винер пытался автоматизировать управление зенитными установками. Ему не вполне удалось достичь поставленных целей, однако его работы послужила началом новой науки — кибернетики. Кибернетика изучает общие механизмы управления — как в машинах, так и в обществе. Кибернетика обрела широкую популярность в советском союзе: создавались новые институты и кафедры, которые пытались автоматизировать работу человека. На одну из таких кафедр, кафедру АСУ (автоматизированных систем управления), я поступила учиться много лет тому назад, благодаря чему вы сейчас имеете возможность читать этот пост.
Ближе к концу XX веке интерес к кибернетике в СССР постепенно стал угасать. Бюджеты были потрачены немалые, а каких-то впечатляющих результатов достичь не удалось. С критикой кибернетики выступал, например, Г.П. Щедровицкий, который говорил о том, что кибернетики изучают процессы управления сами по себе, безотносительно человеческой деятельности и целеполагания:
Те же кибернетические идеи были использованы для создания перцептрона, а затем и нейросетей, которые сейчас бурно развиваются, а про кибернетику все как будто забыли.
Нейросети действительно позволяют очень быстро генерировать много кода.
Однако тот ли этот код, который нам нужен? Тот ли это код, который соответствует нашим целям?
Зависит от целей.
Если вам в принципе все равно, какой там код у вас написан, то тогда шансов “попасть в яблочко” у LLM предостаточно. Для какой ситуации это справедливо? Я уже писала и повторюсь: я считаю, это вполне справедливо для ситуации, когда вы пишете не core часть приложения, а также легко заменяемые плагин.
А что насчет core части?
LLM может хорошо написать любой код при условии достаточно подробной входной спецификации. Здесь кроется проблема: самая подробная спецификация — это… и есть код.
То есть в ситуациях, где важно точное соответствие, кпд LLM-ки стремится к нулю.
Соответственно, наша задача, как разработчиков, сводится к следующему: отделить части системы, которые нам важны, от тех, которые не принципиальны (основной и второстепенный домены в DDD), для вторых организовать процесс агентской разработки, он же харнесс (боже мой, слово-то какое!), а дальше управлять агентами, то есть поправлять агентов в ситуациях, когда их действия расходятся с нашими целями. Управлять при помощи другого агента не получится по определению процесса управления:
Ну а core часть придется писать самостоятельно, иначе нашим целям она будет отвечать очень приблизительно, а легко это изменить мы не сможем.
ИИ заберет у нас самую скучную и рутинную работу. Настоящее проектирование, которое обязательно включает в себя целеполагание, все еще остается за нами.
В сети разгораются нешуточные дискуссии на тему замены разработчиков искусственным интеллектом.
Какой-то сын маминой подруги пишет, как его харнесс (если что, это приличное слово, погуглите) помогает ему делать всю свою работу за два часа, а остальное время пить смузи на пляже. Другой отвечает, что единственное, что создает ИИ — боль, техдолг и проблемы. Пока обыватели пытаются разобраться, пора ли выкинуть на помойку свое резюме программиста и переучиваться на электросварщика, самые умные изучают историю.
Отчетливые попытки заменить человека на машину были еще в середине прошлого века. Во время Второй Мировой войны Норберт Винер пытался автоматизировать управление зенитными установками. Ему не вполне удалось достичь поставленных целей, однако его работы послужила началом новой науки — кибернетики. Кибернетика изучает общие механизмы управления — как в машинах, так и в обществе. Кибернетика обрела широкую популярность в советском союзе: создавались новые институты и кафедры, которые пытались автоматизировать работу человека. На одну из таких кафедр, кафедру АСУ (автоматизированных систем управления), я поступила учиться много лет тому назад, благодаря чему вы сейчас имеете возможность читать этот пост.
Ближе к концу XX веке интерес к кибернетике в СССР постепенно стал угасать. Бюджеты были потрачены немалые, а каких-то впечатляющих результатов достичь не удалось. С критикой кибернетики выступал, например, Г.П. Щедровицкий, который говорил о том, что кибернетики изучают процессы управления сами по себе, безотносительно человеческой деятельности и целеполагания:
“…Однако вскоре Винер, который был аналитиком, увидел, что в этой схеме отсутствует главный момент; и незадолго до своей смерти написал об этом, повернув против всех, кто бросился разрабатывать кибернетику: выпало самое главное, а именно цель, которая есть у наводчика орудия. Цель схватить не удалось….”
Те же кибернетические идеи были использованы для создания перцептрона, а затем и нейросетей, которые сейчас бурно развиваются, а про кибернетику все как будто забыли.
Нейросети действительно позволяют очень быстро генерировать много кода.
Однако тот ли этот код, который нам нужен? Тот ли это код, который соответствует нашим целям?
Зависит от целей.
Если вам в принципе все равно, какой там код у вас написан, то тогда шансов “попасть в яблочко” у LLM предостаточно. Для какой ситуации это справедливо? Я уже писала и повторюсь: я считаю, это вполне справедливо для ситуации, когда вы пишете не core часть приложения, а также легко заменяемые плагин.
А что насчет core части?
LLM может хорошо написать любой код при условии достаточно подробной входной спецификации. Здесь кроется проблема: самая подробная спецификация — это… и есть код.
“Наиболее совершенной моделью кота является такой же кот, а лучше — он сам.” (Н. Винер)
То есть в ситуациях, где важно точное соответствие, кпд LLM-ки стремится к нулю.
Соответственно, наша задача, как разработчиков, сводится к следующему: отделить части системы, которые нам важны, от тех, которые не принципиальны (основной и второстепенный домены в DDD), для вторых организовать процесс агентской разработки, он же харнесс (боже мой, слово-то какое!), а дальше управлять агентами, то есть поправлять агентов в ситуациях, когда их действия расходятся с нашими целями. Управлять при помощи другого агента не получится по определению процесса управления:
“Управление возникает тогда, когда есть отклонение фактического процесса от заданной нормы или траектории, и задача управления — вернуть процесс в нормативное русло.” (Г.П. Щедровицкий)
Ну а core часть придется писать самостоятельно, иначе нашим целям она будет отвечать очень приблизительно, а легко это изменить мы не сможем.
ИИ заберет у нас самую скучную и рутинную работу. Настоящее проектирование, которое обязательно включает в себя целеполагание, все еще остается за нами.
"Отдайте же человеку - человеческое, а вычислительной машине - машинное." (Н. Винер, 1964г)