Как ИИ изменит разработку программного обеспечения: суровые истины от Addy Osmani (глава Chrome Developer Experience)

Всем привет!

Меня зовут Александр, я COO в SaaS-платформе аналитики данных. Последний год активно изучаю внедрение AI-решений в кросс-функциональные процессы. Делюсь материалами, которые помогают:

• Продуктовым менеджерам — интегрировать AI без перегрузки команд;

• Разработчикам — выбирать инструменты под конкретные бизнес-задачи;

• Специалистам по данным — избегать ошибок в production-развертывании.

У себя в телеграм-канале делюсь сжатыми и структурированными саммери статей.

Сегодняшний перевод — The Pragmatic Engineer Как кодирование с помощью ИИ изменит разработку программного обеспечения: суровые истины.
Статья раскрывает реальное положение дел с AI-инструментами для разработки ПО, их преимущества и ограничения в инженерных командах. AI создаёт «парадокс знаний» — больше помогает опытным разработчикам; генерирует «проблему 70%» — быстро создаёт прототип, но требует экспертизы для финишной доработки; и формирует новую парадигму «агентной разработки ПО».

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

Addy Osmani — разработчик ПО и руководитель разработки, находящийся в хорошей позиции для наблюдения за тем, как инструменты GenAI действительно меняют разработку ПО. Он работает в Google 12 лет и в настоящее время является руководителем Chrome Developer Experience. Google — компания, находящаяся на переднем крае инноваций GenAI. Компания является автором исследовательской статьи об архитектуре Transformers, опубликованной в 2017 году, которая служит основой для LLM. Сегодня Google создала одну из самых передовых фундаментальных моделей с Gemini 2.0 и является одним из крупнейших конкурентов OpenAI.

---

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

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

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

1. Как разработчики на самом деле используют AI

Начинающие с нуля: от нуля до MVP

Инструменты, такие как Bolt, v0 и AI для преобразования скриншотов в код, революционизируют способы создания новых проектов. Эти команды обычно:

• Начинают с дизайна или примерной концепции

• Используют AI для создания полной первоначальной кодовой базы

• Получают работающий прототип за часы или дни вместо недель

• Фокусируются на быстрой валидации и итерации

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

Итераторы: ежедневная разработка

Вторая группа использует такие инструменты, как Cursor, Cline, Copilot и WindSurf для своего ежедневного рабочего процесса разработки. Это менее эффектно, но потенциально более трансформативно. Эти разработчики:

• Используют AI для автодополнения кода и предложений

• Используют AI для сложных задач рефакторинга

• Создают тесты и документацию

• Используют AI как «напарника» для решения проблем

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

2. Проблема 70%: парадокс кривой обучения AI

Твит, который недавно привлек мое внимание, идеально отражает то, что я наблюдаю в этой области: неинженеры, использующие AI для программирования, сталкиваются с разочаровывающей стеной. Они могут удивительно быстро пройти 70% пути, но оставшиеся 30% превращаются в упражнение с убывающей отдачей.

Источник: Peter Yang в X

Эта «проблема 70%» раскрывает нечто критически важное о текущем состоянии AI-ассистированной разработки. Начальный прогресс кажется волшебным: вы можете описать, что хотите, и AI-инструменты, такие как v0 или Bolt, сгенерируют работающий прототип, который выглядит впечатляюще. Но затем наступает реальность.

Паттерн двух шагов назад

Что обычно происходит дальше, следует предсказуемому паттерну:

• Вы пытаетесь исправить небольшую ошибку

• AI предлагает изменение, которое кажется разумным

• Это исправление ломает что-то другое

• Вы просите AI исправить новую проблему

• Это создает еще две проблемы

• И так далее

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

Скрытая стоимость «AI-скорости»

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

• Рефакторят сгенерированный код в меньшие, сфокусированные модули

• Добавляют обработку граничных случаев, которые AI пропустило

• Усиливают определения типов и интерфейсы

• Ставят под сомнение архитектурные решения

• Добавляют комплексную обработку ошибок

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

Младшие инженеры часто пропускают эти важные шаги. Они более охотно принимают результаты AI, что приводит к тому, что я называю «карточным домиком» — код выглядит законченным, но разваливается под реальным давлением.

Разрыв в знаниях

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

• Используют AI для быстрого прототипирования

• Уделяют время пониманию того, как работает сгенерированный код

• Изучают базовые концепции программирования наряду с использованием AI

• Постепенно создают фундамент знаний

• Используют AI как инструмент обучения, а не только как генератор кода

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

Парадокс знания

Вот самое контринтуитивное, что я обнаружил: AI-инструменты помогают опытным разработчикам больше, чем начинающим. Это кажется обратным логике. Разве AI не должен демократизировать программирование?

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

Это создает то, что я называю «парадоксом знания»:

• Опытные разработчики используют AI для ускорения того, что они уже умеют делать

• Начинающие пытаются использовать AI, чтобы узнать, что делать

• Результаты кардинально отличаются

Я наблюдал, как опытные инженеры используют AI для:

• Быстрого прототипирования идей, которые они уже понимают

• Создания базовых реализаций, которые они затем могут улучшить

• Изучения альтернативных подходов к известным проблемам

• Автоматизации рутинных задач программирования

Тем временем, новички часто:

• Принимают неверные или устаревшие решения

• Пропускают критически важные аспекты безопасности и производительности

• Испытывают трудности с отладкой кода, сгенерированного AI

• Создают хрупкие системы, которые они не полностью понимают

Здесь есть более глубокая проблема: то, что делает AI-инструменты доступными для неинженеров — их способность обрабатывать сложность за вас — фактически может препятствовать обучению. Когда код просто «появляется», без понимания базовых принципов:

• У вас не развиваются навыки отладки

• Вы упускаете изучение фундаментальных паттернов

• Вы не можете рассуждать об архитектурных решениях

• Вы испытываете трудности с поддержкой и развитием кода

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

Последствия для будущего

Эта «проблема 70%» предполагает, что текущие AI-инструменты для программирования лучше всего рассматривать как:

• Ускорители прототипирования для опытных разработчиков

• Учебные пособия для тех, кто стремится понять разработку

• Генераторы MVP для быстрой проверки идей

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

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

3. Что действительно работает: практические паттерны

После наблюдения за десятками команд, вот что я видел работающим стабильно:

Паттерн «AI-первый черновик»

Позвольте AI сгенерировать базовую реализацию

• Вручную проверьте и проведите рефакторинг для модульности

• Добавьте комплексную обработку ошибок

• Напишите тщательные тесты

• Документируйте ключевые решения

Паттерн «постоянный диалог»

Начинайте новые AI-чаты для каждой отдельной задачи

• Поддерживайте фокусированный и минимальный контекст

• Проверяйте и фиксируйте изменения часто

• Поддерживайте тесные циклы обратной связи

Паттерн «доверяй, но проверяй»

• Используйте AI для первоначальной генерации кода

• Вручную проверяйте все критические пути

• Проводите автоматизированное тестирование граничных случаев

• Внедряйте регулярные аудиты безопасности

4. Что это значит для разработчиков?

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

• Ускорение известного. AI превосходно помогает нам реализовывать паттерны, которые мы уже понимаем. Это как иметь бесконечно терпеливого напарника, который может очень быстро печатать.

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

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

Если вы только начинаете использовать AI-ассистированную разработку, вот мой совет:

Начинайте с малого

• Используйте AI для изолированных, четко определенных задач

• Проверяйте каждую строчку сгенерированного кода

• Постепенно переходите к более крупным функциям

Сохраняйте модульность

• Разбивайте всё на небольшие, сфокусированные файлы

• Поддерживайте четкие интерфейсы между компонентами

• Документируйте границы ваших модулей

Доверяйте своему опыту

• Используйте AI для ускорения, а не для замены вашего суждения

• Подвергайте сомнению сгенерированный код, который кажется неправильным

• Поддерживайте свои инженерные стандарты

5. Расцвет агентной разработки программного обеспечения

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

Что я имею в виду под «агентной»? Вместо простого ответа на запросы эти системы могут планировать, выполнять и итеративно улучшать решения с возрастающей автономией.

Если вам интересно узнать больше об агентах, включая мое мнение о Cursor/Cline/v0/Bolt, вас может заинтересовать мой недавний доклад на JSNation, представленный выше.

Мы уже видим ранние признаки этой эволюции:

От исполнителей к сотрудникам

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

Подумайте об отладке: вместо того, чтобы просто предлагать исправления, эти агенты могут:

• Проактивно выявлять потенциальные проблемы

• Запускать и выполнять наборы тестов

• Проверять UI-элементы и делать скриншоты

• Предлагать и реализовывать исправления

• Проверять работоспособность решений (это может быть большим делом)

Мультимодальное будущее

Следующее поколение инструментов может делать больше, чем просто работать с кодом. Они могут бесшовно интегрировать:

• Визуальное понимание (скриншоты UI, макеты, диаграммы)

• Разговоры на естественном языке

• Взаимодействие с окружением (браузеры, терминалы, API)

Эта мультимодальная способность означает, что они могут понимать и работать с программным обеспечением так, как это делают люди: целостно, а не только на уровне кода.

Автономно, но управляемо

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

Наиболее эффективные команды в 2025 году могут быть теми, которые научатся:

• Устанавливать четкие границы и руководящие принципы для своих AI-агентов

• Устанавливать сильные архитектурные паттерны, внутри которых могут работать агенты

• Создавать эффективные циклы обратной связи между человеческими и AI-возможностями

• Поддерживать человеческий надзор, используя автономию AI

Разработка с ориентацией на английский язык

Как отметил Andrej Karpathy в своем посте:

«Самый горячий новый язык программирования — английский».

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

Этот сдвиг в сторону агентной разработки потребует от нас развития наших навыков:

• Более сильного системного проектирования и архитектурного мышления

• Лучшей спецификации требований и коммуникации

• Большего фокуса на обеспечении качества и валидации

• Улучшенного сотрудничества между человеческими и AI-возможностями

6. Возвращение программирования как ремесла?

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

Источник: Garry Tan в X

Ловушка демо-качества

Это становится закономерностью: команды используют AI для быстрого создания впечатляющих демо-версий. Счастливый путь работает прекрасно. Инвесторы и социальные сети в восторге. Но когда реальные пользователи начинают кликать? Именно тогда всё разваливается.

Я видел это собственными глазами:

• Сообщения об ошибках, которые не имеют смысла для обычных пользователей

• Граничные случаи, которые вызывают сбой приложения

• Запутанные состояния UI, которые никогда не приводятся в порядок

• Полностью игнорируемая доступность

• Проблемы с производительностью на медленных устройствах

Это не просто ошибки P2. Это разница между программным обеспечением, которое люди терпят, и программным обеспечением, которое люди любят.

Утраченное искусство полировки

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

• Одержимость сообщениями об ошибках

• Тестирование на медленных соединениях

• Элегантная обработка всех граничных случаев

• Обеспечение обнаруживаемости функций

• Тестирование с реальными, часто нетехническими пользователями

Такое внимание к деталям (возможно) не может быть сгенерировано AI. Оно происходит из эмпатии, опыта и глубокой заботы о ремесле.

Возрождение персонального программного обеспечения

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

• Гордятся своим ремеслом

• Заботятся о мелких деталях

• Сосредоточены на полноценном пользовательском опыте

• Разрабатывают с учетом граничных случаев

• Создают действительно самодостаточный опыт

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

Итог

AI не делает наше программное обеспечение кардинально лучше, потому что качество программного обеспечения (возможно) никогда не ограничивалось в первую очередь скоростью написания кода. Сложные части разработки программного обеспечения — понимание требований, проектирование поддерживаемых систем, обработка граничных случаев, обеспечение безопасности и производительности — по-прежнему требуют человеческого суждения.

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

Дополнительные мысли

Подходящее время для обновления понимания того, что действительно представляет собой разработка ПО

Большая часть обсуждений инструментов AI для разработки ПО фокусируется на возможностях генерации кода, и не без оснований. AI-инструменты впечатляют в генерации работающего кода из запросов или предложении встраиваемого кода при создании ПО. Но какую часть процесса создания ПО занимает само кодирование? Около 50 лет назад Фред Брукс считал, что это около 15-20% всего затраченного времени. Вот мысли Брукса из книги «Мифический человеко-месяц», написанной в 1975 году:

«На протяжении многих лет я успешно использовал следующее эмпирическое правило для планирования программной задачи:

⅓ планирование

⅙ кодирование

¼ тестирование компонентов и раннее системное тестирование

¼ системное тестирование, когда все компоненты готовы».

По моему мнению, сегодня разработчики ПО, вероятно, распределяют свое время следующим образом:

• 20% планирование

• 40% кодирование (код + тесты)

• 20% ревью кода (других разработчиков)

• 20% подготовка к выпуску + развертывание + мелкие исправления во время этого + мониторинг+оповещения

В то же время, создание выдающегося программного обеспечения включает в себя множество других аспектов:

1. Что: Определите, что нужно создать. Это может включать мозговые штурмы, проектирование, пользовательское тестирование, работу с продуктовыми менеджерами и бизнес-заинтересованными сторонами и т.д. Для стартапов эта фаза может занимать очень мало времени («просто создайте и посмотрите, работает ли это!»). Для устоявшихся компаний это может занимать больше времени, чем само создание («мы должны убедиться, что то, что мы создаем, не запутает наших существующих клиентов!»).

2. Как: Разработайте план создания продукта/функции/сервиса. Продумайте архитектурные последствия, зависимости, как тестировать продукт и т.д. Опять же, стартапы могут пропустить этот этап, и команда может перейти непосредственно к планированию. Но для более крупных компаний с большим количеством сервисов и зависимостей, отсутствие планирования обернется против команды. Поэтому большинство команд проводят некоторое планирование, используя Design docs, RFC или ADR.

3. Создание: Реализуйте функцию или продукт: напишите код и убедитесь, что он работает.

4. Проверка: Дважды проверьте, что всё работает как ожидалось, прежде чем выпускать в продакшн. Это особенно важно в случаях, когда выпуск сопряжен с высокими рисками: например, выпуск регрессии в банковском приложении может иметь финансовые последствия для клиентов и бизнеса! Мы подробно рассмотрели QA в QA across the tech industry.

5. Выпуск: Объедините изменения и доставьте их клиентам. Существует множество стратегий для доставки изменений в продакшн. Мы рассмотрели некоторые из них в Shipping to production.

6. Мониторинг и дежурства: Обнаруживайте, когда что-то не так с продуктом. Если произошел сбой, разрешите его как можно скорее, а затем убедитесь, что подобный сбой не повторится. Мы рассмотрели эти общие подходы в Healthy oncall practices и в Incident review and postmortem best practices.

7. Поддержка: Прислушивайтесь к жалобам и отзывам клиентов, решайте, какие ошибки стоит исправлять, и какие запросы на новые функции приоритетны. И определите, какие отзывы можно игнорировать.

8. Миграция: Если продукт подвергается серьезным изменениям или если технологический стек видит существенные изменения — например, новый фреймворк — может потребоваться миграция. Мы рассмотрели это подробнее в Migrations done well.

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

Обходиться без разработчиков: мечта с 1960-х годов

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

Как создается программное обеспечение (и что такое программное обеспечение — это больше, чем просто код!)

Инструменты GenAI не меняют процесс, но делают некоторые части кодирования более эффективными:

Как инструменты GenAI меняют нашу работу в качестве разработчиков ПО

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

• 1960-е годы: высокоуровневый язык программирования COBOL. COBOL расшифровывается как «common, business-oriented language» (общий, бизнес-ориентированный язык). Заявленной целью этого языка было позволить бизнес-людям без опыта программирования использовать его.

• 1990-е годы: Visual Basic. Язык программирования, предназначенный для очень низкой кривой обучения, плюс визуальная среда, где формы можно создавать с помощью перетаскивания.

• Конец 2010-х: Движение no-code. С помощью шаблонов и визуального редактирования, no-code решения, такие как Bubble, предлагают способ создания программных приложений.

Неудивительно, что несколько стартапов по кодированию на базе GenAI стремятся к той же цели: позволить любому создавать программное обеспечение, используя английский язык. В прошлом мы видели успех для более простых случаев использования. Например, сейчас для создания веб-сайта не требуется знание программирования: нетехнические люди могут использовать визуальные редакторы и сервисы, такие как Wix.com, Webflow, Ghost или WordPress.

Чем выше уровень абстракции, тем сложнее указать, как именно должно работать программное обеспечение. No-code решения уже столкнулись с этим ограничением. Как пишет консультативный CTO Алекс Хадсон в своей статье The no-code delusion:

«Разработка этих синтаксисов обычно сталкивалась с проблемой выразительности: как только они становились достаточно простыми для быстрого освоения, они уже не были достаточно выразительными для использования во многих сценариях. И наоборот: некоторые языки имеют возможность определять в них специализированный язык, называемый предметно-ориентированными языками (DSL).

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

Для более сложного программного обеспечения трудно представить, что не потребуется участие разработчиков ПО в планировании, создании и поддержке программного обеспечения. И чем больше GenAI снижает барьер для нетехнических людей в создании программного обеспечения, тем больше будет программного обеспечения, требующего поддержки.

AI-агенты: большое обещание, но также и большая «неизвестность» для 2025 года

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

С другой стороны, AI-агенты находятся в зачаточном состоянии. Большинство из нас их широко не использовало. Существует только один общедоступный агент, Devin, по цене $500/месяц, и первые отзывы неоднозначны.

Много венчурного финансирования будет направлено в эту область. Мы увидим запуск большего количества инструментов AI-кодирования с агентами, и цена, безусловно, снизится в результате. GitHub Copilot, вероятно, сделает что-то вроде Copilot Workspace (агентный подход) общедоступным в 2025 году. И мы, вероятно, увидим продукты от стартапов, такие как то, что основал бывший технический директор Stripe, Дэвид Синглтон (/dev/agents.)

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

Спрос на опытных разработчиков программного обеспечения может возрасти

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

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

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

---