Поговорить с Дмитрием Рожковым о будущем программирования мы напросились после его видео с тестированием AI программистов. Эксперимент Дмитрия вызвал бурные обсуждения в IT-сообществе и поднял множество вопросов о роли искусственного интеллекта в разработке ПО. Мы решили углубиться в тему и узнать из первых уст, насколько сегодня реальна угроза замены человека-программиста искусственным интеллектом.

Полную версию интервью, организованного нашей компанией Artezio, можно посмотреть на канале Ai4Dev на Youtube. А еще у нас появился Telegram-канал для разработчиков, которые используют ИИ. В нем можно обмениваться мнениями и реальными кейсами.

«Ждать от нейросети, что она с одной попытки все напишет правильно — большая ошибка»

Дмитрий, расскажите, почему вы решили протестировать эти AI-инструменты и как выбирали продукты для тестирования?

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

AI-агенты попали в зону моих интересов частично из-за моей медийной деятельности, а также потому, что я все еще считаю себя разработчиком. Выбор инструментов для тестирования начался с нашумевшего проекта Devin. Однако, поскольку Devin находится в закрытой бета-версии, я решил исследовать другие доступные инструменты на рынке, предпочтительно с открытым исходным кодом или доступные по подписке.

Дмитрий Рожков

Первым я протестировал Devica, которая появилась вскоре после анонса Devin. Devica предоставляет среду разработки с чатом для общения с агентом, виртуальным интернет-браузером, консолью и виртуальной IDE для написания кода.

Затем я попробовал Coursor — IDE с функциями искусственного интеллекта. Интерфейс стремится перевернуть традиционную IDE, позволяя пользователям писать инструкции агенту вместо прямого написания кода.

Следующим был Aider — инструмент для терминала, который, на мой взгляд, наиболее органично вписывается в текущий рабочий процесс программистов.

Наконец, я протестировал инструмент от компании Replit. Они предоставляют хостинг и разработали агента, позволяющего писать код прямо на их сервисе, сразу же его развертывать и оплачивать хостинг. Это часть их стратегии по привлечению большего числа пользователей и демократизации разработки.

При выборе инструментов для тестирования я ориентировался на те, которые были наиболее обсуждаемыми в сообществе разработчиков. Конечно, я не смог охватить все доступные варианты. Например, я пробовал Openhands, но он совершенно не заработал в моем случае.

Интересно отметить, как быстро развивается эта область. Буквально на следующий день после выхода моего видео компания OpenAI выпустила новую модель O1. А совсем недавно я написал пост о появлении еще двух инструментов, работающих в том же направлении. Прогресс в этой сфере исчисляется неделями, что делает любой обзор или тестирование быстро устаревающими. По сути, мое видео с тестированием потеряло актуальность практически сразу после публикации.

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

Я себе сказал, представим, что я блогер с большим количеством видеоматериалов. Мне нужен сервис, который бы принимал видео или аудиофайлы, расшифровывал их в текст, затем сжимал этот текст и создавал оглавления для YouTube в определенном формате. Задача кажется довольно простой и хорошо формализуемой. Более того, я даже указал, какие сервисы следует использовать, поскольку сам уже пользуюсь ими и имею собственный код для этих задач.

Во время тестирования я столкнулся с рядом проблем. Некоторые агенты, например, начали писать код на Python, хотя я явно просил использовать TypeScript. Стоит отметить, что Cursor и Aider корректно использовали TypeScript, как и было запрошено. Однако, должен сказать, что ни один из проектов, созданных различными агентами, изначально не запустился и не был полностью готов к использованию, независимо от используемого языка программирования или качества самого кода.

Так как агенты начинали писать на Python, у меня были интересные переписки с ними. Например: «Эй, а разве можно в TypeScript запустить файл с расширением .py?» «Нет, это расширение для Python». Я говорю: «Да, но я-то попросил написать на TypeScript». Тогда они извинялись и переписывали все на TypeScript, но тоже с определенной степенью отсутствия качества.

Второй момент, который я обнаружил: код они пишут, но если использовать такие среды, как Node.js и TypeScript, требуется довольно много обертки, чтобы TypeScript на Node.js заработал. Нужно настроить сам компилятор TypeScript, но никто из ИИ-агентов этого не делал. Они просто честно написали код, который невозможно было запустить. Чтобы его запустить, нужно было еще немного поработать, все настроить, и не всегда это получалось.

И в этом-то и проблема. Получается, что с одной стороны они пишут код, с другой стороны они пишут только код. В тех средах, где этого достаточно, например, если это Python, у вас есть код и зависимости. Вы устанавливаете зависимости из файла requirements.txt и все работает. А с TypeScript много разных вариантов.

Плюс, наверное, самая большая ошибка — ожидать от нейросети, что она действительно с одной попытки обязательно все напишет правильно. По своим проектам я замечал, что нейросеть гораздо лучше справляется и помогает, когда уже есть какой-то код. Когда у проекта есть определенные зависимости, на которые она может ссылаться, смотреть и делать по примеру. В этом плане, возможно, мой эксперимент был сконструирован не совсем корректно. Но так как я использую в основном JavaScript и TypeScript, мне было интересно проверить возможности сети именно с моими языками программирования.

Почему эти агенты не пишут сразу качественный код?

Я не углублялся конкретно в то, как агенты разбивают задачу и как ее исполняют. Важно отметить, что не все агенты изначально писали код на Python. Однако я предполагаю, что Python может быть для них предпочтительным языком, и это часто демонстрируется в примерах. Мое предположение основано на том, что в обучающей выборке должно быть больше примеров кода на Python, особенно учитывая его популярность на таких платформах, как GitHub.

Интересно, что я даже писал пост в своем Telegram-канале о том, что языки, которые мы традиционно не считаем «красивыми», например PHP, могут стать более востребованными для AI именно из-за большого объема существующего кода. Чем больше кода написано на языке, тем больше материала для обучения нейросети, что потенциально может повысить эффективность AI при работе с этим языком.

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

«Воспроизвести гибкость и эффективность человеческого мышления в контексте программирования пока не удается»

В последнее время мы наблюдаем тенденцию интеграции сред выполнения кода непосредственно в интерфейсы AI-моделей. У Claude это реализовано через «артефакты», OpenAI экспериментирует с похожими решениями. Как вы оцениваете влияние этих встроенных песочниц на эффективность AI в разработке? Насколько возможность немедленного выполнения и тестирования сгенерированного кода приближает нас к созданию полноценного AI-ассистента для программистов?

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

Во-первых, код нужно где-то запустить. Следовательно, у AI-агента должны быть программные интерфейсы для работы с кодом и платформой выполнения. Именно поэтому создание песочниц становится важным направлением. Этим, например, занимаются Replit, предоставляя песочницу прямо на своем сайте. Также есть Canvas от Open AI, который я недавно тестировал, и StackBlitz с их новым сервисом bolt.new. Все эти платформы движутся в схожем направлении. Существует также Aider, который работает прямо из терминала и может выполнять код на локальной машине, хотя тут могут возникнуть вопросы безопасности.

На самом деле, процесс программирования включает множество таких моментов. Мы читаем документацию, ищем информацию в Google, изучаем API, а затем пытаемся адаптировать эти знания под нашу конкретную задачу. Я не утверждаю, что нейросеть не может этого делать, но нужно конструировать AI-агента особым образом.

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

Важно понимать, что все эти языковые модели (LLM), работающие с промптами, на самом деле оперируют одним большим промптом, а не серией отдельных сообщений, как может показаться в чате. Каждый новый запрос или уточнение просто добавляется к существующему промпту. Из-за этого, чем дольше мы общаемся с нейросетью в процессе написания программы, тем больше она может терять контекст того, что было в начале разговора. Это создает определенные проблемы, которые необходимо учитывать при разработке AI-ассистентов для программирования.

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

Возвращаясь к вопросу о песочницах и интеграции сред выполнения, важно отметить, что компании, работающие над AI для программирования, стремятся создать комплексные системы. Эти системы позволяют нейросетевым агентам взаимодействовать с различными компонентами разработки. Речь идет о платформах для запуска кода и обработки ошибок, доступе к интернету для поисковых запросов и сбора информации из документации и других источников. Кроме того, нужны векторные базы данных для эффективного поиска и извлечения релевантной информации, например, RAG поиск, а также инструменты для создания и управления картой репозитория кода.

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

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

В ходе вашего тестирования различных AI-агентов, какие из них показали наилучшие результаты в решении поставленной задачи? Какие факторы, по вашему мнению, определили их превосходство? Заметили ли вы значительную разницу в качестве кода, генерируемого разными системами?

Наиболее впечатляющие результаты показал Cursor Composer, работающий на базе модели Claude 3.5 от Anthropic. Хочу отметить, что я не тестировал отдельно артефакты Anthropic, а использовал интегрированное решение в рамках моей подписки на Cursor.

Однако важно подчеркнуть, что технологии в этой области развиваются стремительно. Уже после завершения основного эксперимента я обнаружил, что сервис bolt.new предоставляет еще более качественные результаты. Этот инструмент создал хорошо структурированный код, разбив мою задачу на логические модули с четкой архитектурой. Он создал индексный файл как точку входа и разделил функциональность на отдельные модули, что значительно повышает читаемость и поддерживаемость кода.

Для сравнения, Canvas от OpenAI сгенерировал код в виде одного большого блока, что напоминает мой собственный стиль написания черновиков или прототипов. Хотя это и отражает распространенный подход к быстрому прототипированию, я ожидал от AI более структурированного и оптимизированного решения.

Этот опыт подтверждает репутацию модели Claude как одной из наиболее продвинутых для задач программирования на момент проведения теста. Однако он также демонстрирует, насколько быстро развивается эта область, и как новые инструменты могут предложить еще более совершенные решения за короткий промежуток времени.

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

«Garbage in, garbage out»

Давайте поговорим о сложности взаимодействия с AI-моделями в контексте программирования. Как бы вы охарактеризовали процесс формулировки задачи для AI? Насколько итеративным он обычно бывает, и какой уровень детализации в промпте вы считаете оптимальным для получения качественного результата? Есть ли какие-то особенности или техники промпт-инжиниринга, которые вы находите особенно эффективными при работе с AI в сфере разработки ПО?

Одна из ключевых проблем в работе с нейросетями – это качество входных данных. Люди, которые много работали с языковыми моделями (LLM), приходят к выводу: «garbage in, garbage out». Иными словами, качество ответа напрямую зависит от качества запроса.

Возьмем, к примеру, нейросети для генерации изображений. Казалось бы, просто: напишешь «красивый котик на закате» – и получишь соответствующую картинку. Но если вам нужен конкретный образ, который вы представляете, возникают сложности. Как описать его так, чтобы получить именно то, что вы хотите?

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

Интересно, что ни одна из тестируемых моделей не предложила написать тесты к коду. Это удивительно, учитывая, что тестирование – общепризнанная лучшая практика в разработке, помогающая верифицировать программу.

Что касается детализации промпта, я склоняюсь к тому, что он должен быть на человеческом языке и не слишком подробным. Иначе написание промпта для простой задачи может занять столько же времени, сколько и написание самого кода. Я видел примеры, где люди используют промпты на 200 строк, детально описывающие структуру базы данных и ORM на TypeScript. Но это уже похоже на то, что вы написали половину кода сами, а потом говорите, что это сделала нейросеть.

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

Количество итераций при работе с AI зависит от пользователя. Я пришел к выводу, что целевая аудитория этих инструментов – люди, понимающие основы программирования. Они должны уметь читать код, знать о переменных, циклах, зависимостях, уметь запускать и тестировать код. По сути, это должен быть как минимум грамотный тестировщик, понимающий внутренние процессы, а не просто работающий по принципу «черного ящика».

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

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

Вопрос о том, может ли человек без навыков программирования создать программу самостоятельно с помощью LLM, довольно сложный. С одной стороны, современные языковые модели имеют встроенные механизмы обработки ошибок и способны итеративно улучшать код. Теоретически, даже непрограммист может определить, работает программа или нет.

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

Например, в моем тесте было несколько взаимосвязанных задач: загрузка файла в удаленное хранилище, преобразование его в текст, сжатие текста, создание глав для YouTube и публикация поста в блоге. Это уже довольно сложная цепочка действий.

С другой стороны, есть примеры, когда люди создают простые веб-интерфейсы, обращающиеся к одному-двум API, используя Python — язык, хорошо знакомый нейросетям. В таких случаях за 30-40 минут работы с различными промптами можно получить рабочий результат.

Ключевой вопрос здесь — эффективность использования времени. Стоит ли менеджеру тратить целый день на общение с нейросетью вместо выполнения своих прямых обязанностей? Если ценность созданного продукта превышает потенциальную ценность других задач менеджера (например, общения с клиентами или оптимизации процессов), то такой подход может иметь смысл. Однако часто эффективнее поручить работу с нейросетью джуниор-разработчику, у которого уже есть базовые знания в программировании. Это позволит получить результат быстрее и качественнее.

В свете развития AI-технологий, как вы оцениваете будущее профессии программиста? Многие компании инвестируют в платформы, где клиент может заказать сайт «в один клик», и AI якобы сделает всю работу. Считаете ли вы это реалистичным сценарием или больше маркетинговым ходом?

Я склоняюсь к тому, что такой сценарий возможен, но с некоторыми оговорками. Важно понимать, что для AI нет принципиальной разницы между написанием сложного алгоритма, используемого на собеседованиях, или простого кода для сохранения данных в базу. Однако существуют ограничения, которые нужно учитывать. Это качество входных данных и обучающей выборки AI, ограничения контекстного окна, с которым работает нейросеть, а также сложность интеграции различных компонентов системы.

В моих тестах я заметил, что модели лучше справляются с более простыми, изолированными задачами, но начинают испытывать трудности, когда требуется создать систему с большим количеством взаимосвязанных компонентов. Например, AI не может просто взять и запустить код на вашем компьютере — для этого нужна дополнительная инфраструктура и настройка.

Поэтому, хотя идея «сайта в один клик» звучит привлекательно, реализация такой системы требует решения множества технических и организационных вопросов. Это не невозможно, но и не так просто, как может показаться на первый взгляд. Ключевой вызов заключается не столько в написании кода, сколько в создании целостной, интегрированной системы, способной работать в реальных условиях.

Как вы оцениваете новые подходы к генерации кода AI, в частности, системы вроде O1 превью? Насколько, по-вашему, такие инновации могут повысить качество программирования с помощью AI-ассистентов? Какие подходы сейчас наиболее распространены в этой области?

Мне кажется, если посмотреть на O1 превью, то они просто упаковали то, что некоторые люди, так называемые промпт-инженеры, делали самостоятельно. Один мой знакомый пошутил, что профессия промпт-инженера не успела появиться, а ее уже автоматизировали.

Штука в том, что это действительно повышает качество выхода. Я смотрел интервью с Максимом Страховым на «Подлодке», по-моему, где он очень подробно рассказывает, как работает LLM. В частности, он рассказывает об одном из своих кейсов, где он просил нейросеть сгенерировать хокку, японский стишок. А вторым запросом он спрашивал, похоже ли это на хокку. То есть он ту же самую нейросеть без предварительного контекста просил верифицировать результат. И этот второй запрос значительно улучшал выход.

Получается, что если ответ «нет, не похоже, это не хокку», то мы запускаем цикл еще раз и, допустим, пробуем этот цикл 10 раз. Если через 10 раз хокку не сгенерировалось, мы падаем с ошибкой или идем на следующий шаг. Этот момент генерации, верификации и, возможно, повтора действительно драматически улучшает качество выхода.

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

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

«Программисты говорят, что сложные системы ИИ пока не умеет писать — это их защитная реакция»

Насколько сложные проекты можно делать с помощью AI-ассистента? Разработчики, с которыми мы общались, считают, что только простые — какой-нибудь сайт, бот, и всё. А что-то сложное, какую-то мультимодальную систему, сделать практически невозможно. То есть если мы говорим про какой-то банк, то там нельзя комплексно применить AI. Можно по сути написать код, но комплексно реализовать нет. Что вы думаете об этом?

Я думаю, что это примерно та же проблема. Это не про сложность алгоритмов, потому что по большому счету нейросети все равно, какой сложности код она генерирует. Она одинаково быстро генерирует код, который пишет «Hello World», или который реализует алгоритм Union-Find. Ей все равно.

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

У нас есть, допустим, какой-то архитектор, который просто рисует UML-диаграммы и примерно понимает, как эта система работает. Потом у нас есть каждый отдельный кирпичик, который представляет группу систем, разбивающуюся на организации. В этих организациях системы разбиваются на команды. Команды пишут микросервисы. А потом это все интегрируется вместе. И, соответственно, это все собирается снизу вверх. У нас есть какие-то метрики на дашбордах. И по этим показаниям мы делаем выводы.

Мне кажется, что проблема состоит не в том, что нейросеть не способна написать этот код. Проблема в том, что мы пока еще не научились преодолевать эти, как говорят в английском, «air gaps» — промежутки между системами. Нужно научить нейросеть как-то передавать информацию через эти промежутки.

Допустим, у нас есть техническая документация, толстая книга по разработке банковской системы. Эту документацию кто-то должен прочитать всю. Но даже если он ее всю прочитает, он ее всю не запомнит. Соответственно, этот человек будет делать конспект. Конспект по факту — это суммаризация текста. Эта проблема решена. То есть каждая отдельная маленькая проблема может быть решена нейросетью. Но связать вместе — проблема. Разработчики ИИ как раз сейчас и работают над ее решением. Они пытаются заполнить эти промежутки чем-то, каким-то «эфиром», который нейросеть тоже сможет использовать.

Мне кажется, развитие идет в этом направлении. А то, что программисты говорят, что такие сложные системы нейросеть пока не умеет писать, мне кажется, это своего рода защитная реакция.

Развитие AI-ассистентов и систем автоматической генерации кода повлияет на профессию программиста в ближайшем будущем? Ожидаете ли вы значительного сокращения числа разработчиков или изменения структуры спроса на рынке труда?

Сложный вопрос. Некоторые люди говорят, что просто будем писать больше программ. С другой стороны, как показывает ситуация в экономике США и Европы после ковидного сдувания пузыря, когда уволили десятки тысяч программистов, как будто бы оказалось, что не нужно столько программ. Кончились бесплатные венчурные деньги, и их перестали осваивать в различных мобильных приложениях, условно. Почему создание нейросети вдруг должно увеличить количество программистов, если даже без нейросети программистов десятки тысяч сократили? Это вопрос, на который нужно сперва ответить. У меня ответа на него, наверное, нет.

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

Если где-то произошла ошибка, она идет обратно в начальные требования. Это тот момент, о котором я говорил в первом своем видео про идеального искусственного программиста. Какая проблема у живых программистов? Когда приходят новые требования, мы должны как-то вкорячить их в уже написанную систему. Но искусственному программисту не надо вкорячивать. Он просто перепишет всю систему с нуля идеально с новыми требованиями.

«Нужно потратить время, разобраться»

А сам LLM не может создать свой язык программирования, который позволит успешно контролировать результативность работы ИИ людям без опыта в программировании?

По большому счету, такие попытки были сделаны с различными языками, вроде Rust. Язык Rust славится своими сообщениями об ошибках — там все подробно описано: что произошло, где, куда посмотреть. Теоретически, мне кажется, это не нейросеть должна сделать такой язык для себя. Это должны сделать люди, у которых задача будет сказать: «Окей, сообщения об ошибках этого языка программирования должны быть написаны на простом английском языке, без строчек кода, без чего-либо». Но строчки кода опять-таки нужны людям, чтобы можно было понять, куда надо пойти посмотреть, что сделать. И эту связку надо как-то будет все равно сохранить.

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

Какой совет вы дадите программистам, разработчикам, которые хотят попробовать использовать AI в своей работе? Исходя из вашего теста, какие подводные камни, прежде всего, надо учесть? И, вообще, насколько все это применимо сегодня уже?

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

В программировании есть концепция «протекающей абстракции». Она подразумевает, что для эффективного использования инструмента необходимо понимать его внутреннее устройство. Я рекомендую посмотреть несколько интервью или докладов, где эксперты подробно объясняют, как нейросети обрабатывают запросы. Это знание поможет вам формулировать более эффективные промпты и взаимодействовать с AI более осознанно.

Понимание принципов работы AI-ассистентов позволит вам получать значительно более качественные результаты. Вы сможете лучше предвидеть, какие запросы дадут желаемый output, и как интерпретировать полученные ответы. В итоге, это не только повысит продуктивность вашей работы, но и поможет избежать типичных ошибок при использовании AI в программировании.

Как я говорил раньше, если мусор на входе, мусор будет на выходе. И если человек просто приходит в нейросеть и пишет: «Создай мне TikTok», а нейросеть что-то делает, но не получается, и человек говорит: «Ахаха, ты не умеешь писать код» — это очень высокомерная позиция, мне кажется. Нужно потратить время, разобраться.

Почему мы не видим сегодня новых TikTok-ов или программ, которые созданы нейросетями. Получилось, что на рынок вышло много непрограммистов, но мы не видим бума новых идей, новых программ.

Потому что, как оказалось, программирование — это не самая сложная часть. Во-первых, нужна сама идея продукта, которая решает реальную проблему или удовлетворяет потребность пользователей. Генерация и валидация такой идеи – это отдельный навык, который не заменишь AI.

Во-вторых, даже имея идею, необходимо ее правильно валидировать. Это требует понимания рынка, пользовательских потребностей и бизнес-процессов. AI может помочь в анализе данных, но интерпретация результатов и принятие решений остаются за человеком.

Наконец, самая сложная часть – это маркетинг и привлечение аудитории. Создать приложение с помощью AI возможно, но заставить людей его использовать – это совсем другая задача.

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

Таким образом, отсутствие бума новых приложений связано не с ограничениями AI в разработке, а с комплексностью процесса создания успешного продукта, где программирование – лишь одна из многих составляющих.