Transcription
Приветствую всех. Сегодня у нас очень актуальная тема: разработка программного обеспечения. Точнее, то, как она, ну, просто меняется на глазах. Да, изменения действительно колоссальные происходят. И всё это, конечно, под влиянием искусственного интеллекта.
Вот мы сегодня хотим сфокусироваться на одном конкретном инструменте — Cloud Code. Его делает компания Anthropic. Угу. Anthropic, известные своими большими языковыми моделями. Именно. И мы попробуем разобраться, как вообще за последний год эволюционировали вот эти ИИ-помощники для программистов. Что такого особенного в Cloud Code? И, ну, главный вопрос, как это всё может, ну, не знаю, перевернуть привычную работу инженеров.
Да, вопрос действительно важный, потому что затрагивает, ну, очень многих. А опираться мы будем на интересный материал. Это беседа Алекса, он в Anthropic отвечает за связи с разработчиками, и Бориса. А Борис — это, собственно, технический сотрудник и, ну, можно сказать, создатель Cloud Code.
О, это ценный источник. Взгляд изнутри, так сказать. Да, из первых рук. Их разговор даёт нам, ну, такую редкую возможность посмотреть на технологию именно изнутри. Так что наша задача сегодня — уловить вот эту суть трансформации, понять, что это значит для всех, кто, ну, хоть как-то связан с кодом.
Согласен. Давайте попробуем разложить по полочкам.
Итак, с чего всё начиналось? Вот давайте отмотаем на год назад. Как тогда выглядел кодинг? Си Борис ведь вспоминал об этом?
Да, вспоминал. И картина, надо сказать, была совершенно другой. Год назад. Ну, что было вершиной прогресса в этой области?
Наверное, автодополнение в IDE.
Именно автодополнение. Ну, может, ещё какие-то базовые подсказки и, конечно, копирование кусков кода из чат-ботов. Типа: спросил у условного ChatGPT, как сделать X. Он выдал код, ты скопировал, вставил, и подправил напильником потом, скорее всего.
Ну да, адаптировал под свой проект. Вот это, по сути, и был передний край год назад. Казалось, что это уже ну очень круто.
А сейчас смотришь, кажется, что это было в прошлой жизни. Хотя прошёл всего год. Невероятно просто.
Действительно, скорость изменений поражает. И Борис как раз выделяет ключевой сдвиг, который произошёл за этот год.
Какой?
Это переход от ИИ как простого помощника к ИИ как полноценному агенту. Агент, который встроен прямо в твой рабочий процесс.
Агент звучит немного по-фантастически. Что это значит на практике?
А это значит, что ИИ — это уже не просто, ну, там, отдельные подсказки или генерации каких-то фрагментов кода по запросу. Это, э, это система, которой ты делегируешь задачи. Борис формулирует это так, цитирую: "Теперь, когда вы пишете код, вы используете агента. Вы больше не манипулируете текстом в IDE напряную".
То есть я больше не печатаю `public static void main`?
Ну, можешь и печатать, если хочешь. Но суть в том, что ты переходишь от прямого редактирования, от манипуляции символами, строчками кода к управлению моделью. Ты говоришь модели, что нужно сделать, а она сама выполняет эти манипуляции с текстом, с кодом.
Хмм, интересно. То есть я как бы становлюсь таким дирижёром для ИИ-оркестра, который играет код?
Отличная аналогия, да? Что-то вроде того. Ты задаёшь направление, ставишь задачу, а агент её исполняет. И вот этот переход от ручного труда к управлению — это, наверное, самое фундаментальное изменение за год.
Это очень интересно перекликается с другой аналогией Бориса про его школьные годы и калькулятор TI. Он же рассказывал, да?
Да-да-да. Рассказывал, сидел на задней парте, писал программки на Бейсике, чтобы калькулятор сам тесты решал.
Вот. И он говорил, что это было просто доступно. Было такое, знаете, чувство контроля. Ты придумал, ты быстро реализовал, получил результат. А потом...
А потом индустрия пошла по пути усложнения. Появились фреймворки, ну, громоздкие стеки: React, Next.js, Vue, Angular, системы сборки типа Webpack или Vite, контейнеризация, облака.
Да уж, чтобы просто "Hello, World!" вывести, иногда нужно целую инфраструктуру поднять.
Именно. И вот эта сложность, она как бы создала пропасть между идеей, тем, что ты хочешь сделать, и её реализацией. Нужно было преодолеть кучу технических заморочек.
И что? Агенты теперь возвращают нас к той простоте TI? Ну, условно, конечно.
В каком-то смысле, да. Не то, чтобы они убирают всю сложность — понимать, как всё работает, всё равно нужно. Но они берут на себя огромную часть вот этой рутины, связанной с современными стеками.
То есть мне не нужно больше руками настраивать конфиг Webpack на 100 строк?
Ну, в идеальном мире агента, да. Ты можешь сказать: "Настрой мне проект на React, TypeScript и Tailwind", и он это сделает. Или: "Добавь логирование во все эндпоинты", и он пройдётся по коду и добавит. Это позволяет сместить фокус.
Сместить с чего на что?
С деталей реализации, как именно написать этот код, какой синтаксис у этой функции, как настроить CI/CD, на саму суть задачи, на то, что мы хотим получить в итоге, какую бизнес-проблему решить, какую ценность для пользователя создать.
То есть больше времени на продукт и меньше на технические дебри.
Именно. Конечно, это не значит, что технические знания не нужны. Наоборот, чтобы эффективно управлять агентом, нужно понимать, что он делает. Но вот этот барьер для воплощения идей, он, кажется, действительно снижается. Возвращается то чувство, что ты можешь быстро что-то попробовать, создать прототип.
Очень интересно. А как сам Cloud Code появился? Борис же рассказывал про его зарождение.
Да, и это тоже показательная история. Он говорит, что даже самые-самые первые версии, которые работали ещё на моделях попроще, ну, типа Claude 3.5.
Это не самая мощная их модель. Да.
Да. Opus считается флагманом. Так вот, даже на Claude 3.5 первые прототипы Cloud Code оказались, ну, на удивление, полезными практически сразу.
Сразу — это как?
Он привёл пример: сделал какой-то первый набросок инструмента, показал небольшой группе инженеров в Anthropic, просто показал, объяснил идею, а буквально на следующий день он заходит в офис и видит, что они уже им пользуются в своей реальной ежедневной работе.
Ничего себе. Без принуждения, без специальных заданий?
Именно. Я просто вошёл и увидел Cloud Code на их экране в первый раз. Вот его слова. И это, наверное, лучший комплимент для любого разработчика инструмента, когда люди начинают им пользоваться добровольно и сразу видят пользу.
Да уж, это точно показатель того, что ты попал в больную точку, решил реальную проблему.
Безусловно. И это подводит нас к ещё одной важной идее, о которой говорил Борис, — концепции совместной эволюции, или коэволюции.
Коэволюция звучит научно. Что имеется в виду?
Имеется в виду, что успех таких инструментов, как Cloud Code, он зависит не от одного фактора, а от двух, которые развиваются параллельно и влияют друг на друга.
Так, каких двух?
Первый фактор — это, конечно, сама базовая ИИ-модель, её мощность, её способность понимать контекст, генерировать код, рассуждать. Переход с Claude 3.5 Opus на 4.0, потом на 4.1 — это как раз про улучшение самой модели.
Логично, модель становится умнее, инструмент работает лучше.
Да, но это только половина истории. Второй и не менее важный фактор — это то, что Борис называет "сбруей" или "седлом". Ну, по-английски "harness".
Седло для ИИ-лошади?
Отличная аналогия. Он её как раз и использует. Модель — это как дикая, неубузданная, но очень сильная лошадь. А Cloud Code — это вот то самое седло, уздечка, стремена, которые позволяют этой мощью управлять.
То есть сам интерфейс, инструменты вокруг модели?
Именно. Это само приложение Cloud Code, его интерфейс, то, как он интегрируется в IDE или терминал, то, как он управляет контекстом, какие файлы подтягивает, какую историю помнит, какие системные промпты используются, чтобы направить поведение модели в нужное русло. Все вот эти вспомогательные механизмы.
Понятно. И качество этого "седла" так же важно, как и сила лошади?
Абсолютно. Борис подчёркивает, что без хорошей "сбруи" даже самая мощная модель может оказаться бесполезной или даже вредной. Ты просто не сможешь её контролировать, направить её энергию в продуктивное русло. Поэтому прорывные инструменты — это всегда результат инноваций и в самом ИИ, и в способах взаимодействия с ним. Они должны развиваться вместе.
Это коэволюция. Получается, они улучшали и модель, и сам Cloud Code параллельно?
Да, и ключевую роль в улучшении вот этой "сбруи", самого Cloud Code, сыграла культура внутреннего использования продуктов Anthropic. То, что называют "dogfooding".
"Dogfooding" — есть собственную собачью еду. Звучит не очень аппетитно.
Ха, да, термин специфический. Но суть в том, что разработчики сами активно пользуются тем инструментом, который создают. Инженеры Anthropic использовали Cloud Code для своей повседневной работы над, ну, над другими продуктами Anthropic, возможно, даже над самим Cloud Code.
И это давало быструю обратную связь?
Не просто быструю, а моментальную и очень качественную. Борис прямо говорит, насколько критически важным был простой, упрямый канал для этой обратной связи. У них это был выделенный канал в Slack.
Просто чатик для багов и предложений?
Да, но фишка была не просто в сборе отзывов, а в реакции на них. Он рассказывал, что если кто-то сообщал о баге, его могли пофиксить буквально за несколько часов. Если кто-то предлагал улучшение, его могли быстро внедрить. И, что важно, всегда сообщали тому, кто дал фидбэк: "Спасибо, исправили" или "Отличная идея, внедрили".
То есть люди видели, что их мнение реально учитывается.
Именно. И это создавало атмосферу доверия и, ну, такой мощный, непрерывный поток очень ценной информации от реальных пользователей, которые глубоко понимают и инструмент, и проблемы, которые он решает. Это гораздо ценнее, чем, скажем, просто опросы или формальные usability-тесты.
Понимаю, живой диалог с пользователями, которые сами же и разработчики.
Да. И вот этот опыт, основанный на реальном использовании и быстрой обратной связи, он как раз и показывает, почему стандартные синтетические бенчмарки, ну, типа SWE-bench или HumanEval, имеют свои ограничения.
А что это за бенчмарки?
Ну, это такие наборы тестовых задач для кодеров. Например: "Исправь вот эту опечатку в коде" или "Напиши функцию по описанию". Они позволяют как-то количественно измерить прогресс моделей.
И они бесполезны?
Нет, Борис не говорит, что они бесполезны. Они дают какую-то общую картину, позволяют сравнивать модели между собой, но для оценки реального прогресса в такой сложной и многогранной задаче, как помощь в разработке ПО, их недостаточно.
Почему?
Потому что реальная разработка — это не просто решение изолированных задачек из бенчмарка. Это понимание большого контекста проекта. Это коммуникация с командой. Это отладка, рефакторинг, чтение чужого кода. Синтетический тест всего этого охватить не может.
И что тогда является лучшим индикатором?
А вот тут Борис использует интересное слово — "ощущения". Vibes. Ощущение самих разработчиков, которые пользуются инструментом каждый день. Вот это субъективное: "стало лучше", "стало удобнее", "теперь я могу делать то, что раньше не мог". Это часто оказывается более важным индикатором реального прогресса, чем формальные метрики из бенчмарков.
То есть ощущение разработчиков важнее цифр? Звучит немного ненаучно.
Возможно, но кажется, для таких сложных, комплексных систем, как ИИ-агенты для кодинга, которые глубоко встраиваются в творческий процесс, чисто количественные метрики не всегда отражают полную картину. Важно и то, как инструмент ощущается в работе, насколько он интуитивен, насколько помогает, а не мешает. Особенно, когда инструмент уже достиг определённой зрелости.
Интересный момент. Хорошо, давайте тогда посмотрим пристальнее на сам Cloud Code. Борис говорил, что при его создании было два главных принципа. Какие?
Да, два принципа: простота и "hability".
В смысле взломоустойчивость?
Нет, нет, наоборот. В смысле возможности легко его модифицировать, адаптировать, расширять под свои нужды. Возможность поковыряться внутри, допилить под себя.
А, понятно. Как конструктор LEGO.
Точно, хорошая аналогия. Чтобы пользователи могли сами достраивать инструмент, они были жёстко ограничены тем, что дали разработчики. И для этого предусмотрено несколько механизмов расширения.
В какие, например?
Ну, самый первый и простой способ — это файлы `cloud.md`. Это специальные Markdown-файлы, которые можно положить прямо в репозитории с кодом.
И что в них писать?
А туда можно записать инструкции, специфичные для этого конкретного проекта. Например: "Используй такой-то стиль форматирования кода". "Вот основные архитектурные принципы нашего проекта". "Обрати внимание на вот эти важные соглашения команды". И Cloud Code будет учитывать эту информацию при работе с этим репозиторием.
Удобно. Локальный контекст для каждого проекта.
Да, это база. Потом, конечно, появилась более продвинутая система настроек и разрешений для более тонкого контроля над поведением агента. Но настоящий прорыв в этой "hability" связан с несколькими более мощными вещами.
Какими?
Во-первых, это система хуков (hooks). Её разработал один из инженеров, Диксон, как раз в ответ на запросы пользователей, которым не хватало гибкости.
Хуки, как в Git?
Да, идея похожая. Хуки позволяют тебе встроить свою собственную логику на разных этапах работы агента. Например, ты можешь написать скрипт, который будет выполняться перед тем, как Cloud Code выполнит какую-то команду, или после того, как он сгенерировал код.
И что это даёт? Какие сценарии?
О, массу. Например, после генерации кода можно автоматически запустить линтеры, форматеры или даже юнит-тесты, чтобы сразу проверить корректность. Или перед тем, как разрешить агенту вносить изменения в важные файлы, можно выполнить какие-то дополнительные проверки безопасности или соответствия политикам компании. Это открывает дорогу для очень глубокой интеграции в существующие рабочие процессы и CI/CD пайплайны.
Звучит мощно. А что ещё?
Ещё одна крутая штука — это MCP (Multi-Component Prompt).
Сложное название, что за ним скрывается?
Если упрощённо — это технология, которая позволяет агенту динамически подтягивать релевантный контекст из внешних систем во время работы. Борис приводил примеры. Агент может посмотреть связанное обсуждение в Slack, чтобы лучше понять задачу, или заглянуть в логи ошибок из системы мониторинга типа Datadog, чтобы найти причину бага. То есть агент не ограничен только кодом в репозитории, он может смотреть шире.
Именно. Представьте, насколько это повышает его осведомлённость о проблеме. Он может учитывать не только код, но и обсуждение вокруг него, историю ошибок, возможно, даже документацию из Confluence или тикеты из Jira. Это делает его гораздо более контекстно-зависимым и, ну, потенциально более умным помощником.
Впечатляет. А что-нибудь ещё для "hability"?
Да, самое свежее, о чём упоминал Борис — это пользовательские слэш-команды и субагенты.
Слэш-команды, как в Slack, или вызывают специализированных субагентов, и определять их можно прямо в Markdown-файлах.
То есть и я могу создать свою команду, скажем, `refactor_this`?
Вполне возможно. Или, как приводил пример сам Борис, он сделал для себя команду `git commit`. Эта команда берёт изменения, которые он сделал, и автоматически генерирует сообщение коммита по его личным правилам форматирования, а потом и сам коммит делает.
Ха, избавляет от рутины написания сообщений к коммитам.
Вот именно. И таких кастомных команд, автоматизирующих мелкие, но частые задачи, можно насоздавать сколько угодно. Это уже похоже на создание собственных мини-инструментов или рабочих процессов прямо внутри Cloud Code.
Понятно. То есть `cloud.md`, настройки, хуки, MCP/команды. Всё это вместе и составляет эту философию "hability".
Совершенно верно. И Борис подчёркивает, что все эти механизмы служат одной большой цели.
Какой?
Превратить Cloud Code из просто инструмента для кодирования в, ну, он говорит, в универсальный SDK (Software Development Kit) для построения агентных систем.
SDK для агентов, то есть платформа для создания других ИИ-агентов?
Да, он видит потенциал гораздо шире, чем просто помощь программистам. Любая задача, где нужен интеллектуальный агент, который может взаимодействовать с файлами, с системами, использовать инструменты, выполнять какие-то действия по инструкции, потенциально может быть решена на этой платформе. Это может быть и анализ данных, и управление инфраструктурой, и автоматизация бизнес-процессов, что угодно.
То есть Cloud Code — это не только про написание кода, но и про создание агентов для разных задач.
Похоже, что такова долгосрочная визия: дать разработчикам мощный и гибкий инструмент для построения собственных агентных решений, кастомизированных под их конкретные нужды. Это действительно открывает путь к созданию очень сложных и специализированных систем поверх базовой технологии Anthropic.
Хорошо, с возможностями понятно. Давайте теперь заглянем в будущее. Как Борис видит развитие ситуации, ну, скажем, в ближайшие полгода, год. Мы все останемся без работы?
Хах. Но он так не думает. На ближайшие 6-12 месяцев он ожидает скорее гибридный режим работы.
Гибридный — это как?
Это значит, что ручное написание кода, ну или, вернее, кодинг через управление агентом никуда не денется. Инженер всё ещё будет активно участвовать в создании кода, но параллельно возрастёт значение задач по ревью.
Ревью чего?
Кода, написанного другими инженерами. И этого тоже. Но в большей степени — ревью кода или изменений, предложенных самим ИИ-агентом. Представьте, что агент сам анализирует код, находит потенциальные улучшения или баги и создаёт pull request с предложением их исправить.
А задача инженера — посмотреть этот pull request и решить: принять или отклонить.
Именно. То есть инженер выступает уже не столько как исполнитель, сколько как контролёр, как принимающий решения. Фокус смещается с непосредственного набора символов на клавиатуре на высокоуровневое управление процессом и оценку результатов работы.
И...
Звучит логично. А если посмотреть ещё дальше, скажем, на год-два вперёд.
А вот тут Борис прогнозирует более значительный сдвиг — подъём по стеку абстракций.
Стек абстракций — это как?
Ну, смотрите, сейчас агенты в основном работают на уровне файлов, ну, может быть, отдельных функций или коммитов. В перспективе 12-24 месяца ожидается, что они смогут оперировать на более высоком уровне.
На уровне целых фич?
Да, или даже небольших приложений. То есть ты сможешь поставить агенту задачу не "исправь вот этот баг в файле X", а "реализуй фичу Y по вот этому описанию" или "создай простое приложение Z с таким-то функционалом".
И агент сам разберётся, какие файлы создать, какой код написать, как всё связать.
Да, он сам декомпозирует эту высокоуровневую цель на более мелкие шаги и выполнит их. Это уже переход от ИИ как тактического помощника, который помогает с конкретной строчкой кода, к ИИ как стратегическому исполнителю, способному реализовывать целые куски функциональности.
Вот это уже звучит действительно революционно. Если агенты смогут делать целые фичи, как это отразится на инженерах? Какие навыки будут нужны? Нужно ли всем срочно бежать учить prompt engineering?
Ну, prompt engineering, конечно, будет полезен, но Борис считает, что паниковать и выбрасывать все свои знания не стоит. Фундаментальные вещи...
Какие, например?
Понимание языков программирования, как работают компиляторы, базы данных, сети, алгоритмы, принципы проектирования систем. Всё это, по его мнению, останется критически важным.
Почему? Если агент сам пишет код.
Потому что без этих знаний ты не сможешь эффективно управлять агентом. Ты не сможешь правильно поставить ему задачу, оценить результат его работы, понять, почему он сделал так, а не иначе, и что происходит под капотом. Ты не сможешь отлаживать сложные проблемы, которые неизбежно будут возникать. Так что база никуда не денется.
Хорошо, фундамент остаётся, но акценты всё-таки смещаются.
Да, акценты смещаются и очень сильно. В какую сторону?
В сторону креативности. В сторону генерации идей.
Креативности. Но ведь программирование — это вроде как точная, логическая дисциплина.
Логика важна, конечно, но смотрите: если ИИ-агенты берут на себя значительную часть рутинной технической реализации, что становится самым ценным ресурсом?
Наверное, сама идея, что именно нужно реализовать. Вот способность придумать что-то действительно новое, полезное, оригинальное. Найти нетривиальное решение проблемы, сформулировать видение продукта. Вот это становится главным конкурентным преимуществом человека.
То есть ценность смещается от способности написать сложный код к способности придумать, что именно должен делать этот код.
Совершенно верно. Борис даже бросает такую, ну, довольно провокационную фразу: "Сам код больше не является чем-то драгоценным".
Как это? Код — основа всего.
Он поясняет: драгоценным он перестаёт быть в том смысле, что его ценность определяется не сложностью и трудоёмкостью его написания вручную, а ценностью той идеи, той функции, которую он воплощает. Сам процесс кодинга, конечно, может оставаться увлекательным и важным для многих. Он приводит пример инженера Лены, которая пишет на C++ по выходным просто для удовольствия.
То есть кодить для души можно, но экономическая ценность смещается.
Да. Фокус окончательно переходит с вопроса "как это сделать" (потому что "как" во многом берёт на себя ИИ) на вопрос "что именно мы хотим создать, какой продукт, какую ценность, какую идею воплотить". И это, по сути, означает...
Демократизацию разработки.
Демократизацию разработки, демократизацию инноваций, возможность быстро проверять гипотезы, создавать прототипы, воплощать идеи в жизнь без необходимости собирать огромную команду и тратить месяцы на разработку.
Это может привести к взрыву новых проектов?
Вполне возможно. Борис считает, что это может спровоцировать настоящий взрыв инноваций. И что важно, исходить они будут не только от крупных корпораций с большими R&D бюджетами, но и от одиночек, от небольших команд, от стартапов, тех, у кого есть классная идея, но раньше просто не хватало ресурсов или технических навыков, чтобы её реализовать. Агенты могут стать для них таким усилителем.
Снижают порог входа для создания технологии.
Именно. И это может сильно изменить ландшафт всей IT-индустрии.
Очень интересные перспективы. А в конце разговора Борис дал ещё пару практических советов для тех, кто вот только начинает пробовать Cloud Code или подобные инструменты. Что он рекомендует?
Да, пара дельных советов. Первый может показаться немного контр-интуитивным.
Заинтриговали? Какой?
Новичкам он советует начинать не с того, чтобы сразу пытаться написать какой-то код с помощью Cloud Code.
А с чего тогда?
А с того, чтобы задавать ему вопросы о существующей кодовой базе, использовать его как, ну, такой, умного исследователя.
То есть как Google по коду, только лучше?
Да? Что-то вроде того. Спрашивать: "Как в этом проекте принято добавлять логирование?", "Объясни мне архитектуру вот этого модуля", "Почему вот эта функция написана именно так, а не иначе?". Агент ведь может анализировать не только сам код, но и историю коммитов, Git-комментарии, возможно, даже документацию.
И он сможет объяснить решение, принятое другим разработчиком год назад?
Ну, в теории, да. Анализируя историю изменений и сообщения коммитов, он может попытаться реконструировать логику. Цель этого первого шага — не написать код, а освоиться самим процессом взаимодействия с агентом, понять, как формулировать запросы, как интерпретировать его ответы, научиться использовать его как инструмент для понимания кода, а не только для его генерации.
Понятно. Сначала учимся общаться и исследовать. Хороший совет. А второй...
А второй совет касается уже непосредственно написания или изменения кода. Борис предлагает использовать такой, ну, дифференцированный подход в зависимости от сложности задачи.
Он делит задачи на три категории: лёгкие, средние и сложные.
Да, именно так. Лёгкие, средние и сложные. Лёгкие задачи — это что-то простое, рутинное, где вероятность ошибки мала. Ну, не знаю: переименовать переменную во всём проекте, добавить простой юнит-тест по аналогии, обновить зависимости.
И что с ними делать?
Их Борис советует делегировать Cloud Code полностью. Сформулировать чёткий промпт и пусть делает, возможно, даже не открывая редактор кода, а, например, просто создав задачу в GitHub Issues и отметив её специальным тегом типа `#Cloud`.
Полная автоматизация рутины. Логично. А средние задачи?
Средние задачи — это что-то посложнее, где уже есть варианты реализации, где нужно принять какие-то решения, где агент может не угадать с первого раза. Например, реализовать новый API endpoint по спецификации или добавить поддержку новой фичи в существующий модуль.
И как с ними быть? Не доверять полностью.
Здесь рекомендуется использовать то, что он называет режимом планирования. То есть ты не просто говоришь: "Сделай", а сначала обсуждаешь с Cloud Code план действий.
План в смысле?
Агент предлагает: "О'кей, чтобы реализовать эту фичу, я изменю вот эти файлы, добавлю вот такие функции, использую вот такую библиотеку". Ты смотришь на этот план, можешь его скорректировать, что-то уточнить, утвердить, и только после того, как вы согласовали план, ты даёшь команду на его выполнение.
То есть больше контроля, проверка перед действием.
Да, это снижает риск того, что агент сделает что-то не то или не так, как ты ожидаешь.
Понятно. Ну и третья категория — сложные задачи.
Да, сложные задачи — это уже что-то крупное, нетривиальное. Масштабный рефакторинг, проектирование новой сложной системы, исправление глубоких архитектурных проблем.
Здесь агент бессилен?
Не то чтобы бессилен, но здесь инженер должен оставаться главным. Борис говорит: "инженер за рулём". То есть человек принимает основные стратегические решения, определяет архитектуру, контролирует процесс.
А роль Cloud Code?
А Cloud Code выступает как очень продвинутый второй пилот или штурман. Он помогает исследовать кодовую базу, быстро прототипирует разные варианты решения, генерирует boilerplate-код, пишет юнит-тесты по твоей спецификации, ищет информацию, но основную, самую сложную интеллектуальную работу выполняет человек, а ему активно ассистирует.
Получается такой подход: правильный инструмент для правильной задачи.
Именно. Не пытаться использовать ИИ для всего подряд одинаково, а выбирать режим взаимодействия в зависимости от сложности и критичности задачи. Это позволяет получить максимум пользы от сильных сторон ИИ, минимизируя риски.
Очень практичные советы. Спасибо. Итак, если попробовать подвести какой-то итог нашему сегодняшнему, ну, довольно глубокому погружению...
Да, давайте попробуем сформулировать главное. Мы видим, ну, совершенно очевидно, фундаментальный сдвиг в самой парадигме разработки программного обеспечения.
Да, это уже не просто эволюция инструментов, это, похоже, смена самой сути процесса.
Разработка перестаёт быть исключительно процессом, ну, прямого редактирования текста, набора кода вручную. Она всё больше превращается в процесс управления интеллектуальным агентом, диалога с ним, постановки задач, контроля результатов.
Совершенно верно, от ремесла к управлению, если так можно выразиться.
И это, с одной стороны, открывает просто невероятные возможности для творчества, для скорости реализации идей, для снижения барьеров входа.
Безусловно, потенциал для ускорения инноваций огромен. Но с другой стороны, это ставит и новые вопросы о будущем самой профессии инженера, о необходимых навыках, о том, как будут строиться команды и процессы разработки.
Да, вопросов пока больше, чем ответов. Мы находимся в самом начале этой трансформации.
И вот вы сказали интересную мысль в конце, как пищу для размышлений.
Да, есть такой момент, который меня занимает. Вот смотрите. Если ИИ-агенты действительно делают процесс создания софта проще, быстрее, доступнее, и если сам код, как выразился Борис, становится менее драгоценным, как артефакт сложного ручного труда...
К чему это может привести?
А не изменит ли это фундаментально воспринимаемую ценность самих программных продуктов? Сейчас ведь как часто бывает: чем сложнее технология под капотом, тем больше её ценят, тем выше цена. А если создать сложный продукт становится относительно легко...
Тогда ценность сместится на что-то другое.
Возможно, возможно. Фокус окончательно сместится с технического совершенства реализации на оригинальность и полезность самой идеи, на то, насколько уникальную проблему решает продукт, насколько он удобен, насколько хорошо продуман пользовательский опыт, а не на то, сколько человеко-лет ушло на написание кода.
То есть рынок начнёт больше ценить идею, а не сложность её воплощения.
Может быть, это, конечно, пока только гипотеза, но если это произойдёт, это может повлечь за собой очень серьёзные изменения не только в разработке, но и в бизнес-моделях, в инвестициях, в том, как мы вообще оцениваем инновации в сфере технологий. Возможно, на первый план выйдут те, кто умеют генерировать сильные идеи и быстро их проверять с помощью ИИ-инструментов.
Очень интересная мысль напоследок. Есть над чем подумать.
Определённо. Спасибо большое за этот подробный и, мне кажется, очень важный разговор.
Спасибо вам. И спасибо всем, кто был с нами. До новых встреч.