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

Такой «парадокс знаний» подчеркивает, что ИИ скорее дополняет скиллы опытных специалистов, чем делает разработку доступной для всех. Новичкам же важно воспринимать ИИ как инструмент обучения, но никак не замену знаниям и опыту. Так ли это? 

Подробности в новом переводе от команды Spring АйО.

---

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

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

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

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

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

• Начинают с дизайна или общего концепта

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

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

• Сосредотачиваются на быстрой проверке гипотез и итерациях

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

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

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

• Применяют ИИ для автодополнения кода и предложений

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

• Генерируют тесты и документацию с помощью ИИ

• Привлекают ИИ в роли «напарника-программиста» для решения задач

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

Скрытая цена "скорости ИИ"

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

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

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

• Усиливают типизацию и интерфейсы

• Перепроверяют архитектурные решения

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

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

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

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

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

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

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

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

• Джуны пытаются использовать ИИ, чтобы узнать, что делать

• Результаты при этом разительно отличаются

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

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

• Генерации базовых реализаций, которые они затем дорабатывают

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

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

В то же время новички часто:

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

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

• С трудом отлаживают код, созданный ИИ

• Строят нестабильные системы, работу которых они понимают не в полной мере

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

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

Честные мысли о программировании с ИИ от человека без инженерного опыта:

ИИ может помочь сделать 70% работы, но последние 30% вызывают настоящую головную боль. Постоянно кажется, что делаешь шаг вперёд, а потом два назад из-за новых багов и проблем.

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

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

Шаблон "один шаг вперед, два шага назад"

Дальнейшие события обычно развиваются по предсказуемому сценарию:

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

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

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

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

• Появляются  две новые проблемы

И так по кругу.

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

Ещё одна проблема связанная с парадоксом кривой обучением

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

• Вы не развиваете навыки отладки

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

• Вы не можете анализировать архитектурные решения

• Вам сложно поддерживать и развивать код

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

Пробел в знаниях

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

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

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

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

• Постепенно накапливают знания

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

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

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

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

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

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

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

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

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

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

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

1. Шаблон «Первый черновик от ИИ»

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

• Изучите решение и выполните рефакторинг самостоятельно

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

• Напишите подробные тесты

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

2. Шаблон «Постоянный диалог»

• Создавайте новые чаты с ИИ для каждой отдельной задачи

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

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

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

3. Шаблон «Доверяй, но проверяй»

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

• Обращайте внимание на критически важные фрагменты кода

• Пишите автотесты для corner-кейсов

• Регулярно проводите аудит безопасности

Смотрим в будущее: Настоящая перспектива ИИ

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

1. Ускорение известных решений

ИИ отлично помогает внедрять шаблоны, которые мы уже понимаем. Это как иметь бесконечно терпеливого напарника-программиста, который может печатать очень быстро.

2. Исследование возможностей

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

3. Автоматизация рутины

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

Что это значит для вас?

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

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

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

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

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

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

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

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

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

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

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

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

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

Рост агентного программирования

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

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

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

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

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

Современные инструменты, как правило, просто ожидают наших указаний. Но взгляните на новые функции, такие как использование компьютера Anthropic в Claude или возможность Cline автоматически запускать браузеры и выполнять тесты. Это уже не просто «автодополнение» — эти системы действительно понимают задачи и берут на себя инициативу по их решению.

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

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

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

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

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

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

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

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

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

• Вербальные диалоги на естественном языке

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

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

Автономность под контролем

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

В будущем, к 2025 году, лидерами могут стать те команды, которые научатся:

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

• Создавать надёжные архитектурные шаблоны, в рамках которых могут работать агенты

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

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

Англоцентричная среда разработки

Как отметил Андрей Карпатый:

Английский становится самым популярным новым языком программирования.

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

Переход к агентной разработке потребует эволюции наших навыков:

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

• Более точное определение требований и улучшение навыков коммуникации

• Большее внимание к обеспечению качества и надёжности

• Расширение сотрудничества между возможностями человека и ИИ

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

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

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

Необходимо устранить все шероховатости и исправить ошибки уровня P2, вместо того чтобы сосредотачиваться только на демо сценариях.

В этом году персональное ПО вновь вернётся в центр внимания.

Ловушка уровня "показать демо"

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

Я видел это лично:

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

• Corner-кейсы, которые приводят к сбоям приложения

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

• Полное игнорирование доступности

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

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

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

• Внимания к проработке сообщений об ошибках

• Тестирования в условиях слабого интернет соединения

• Корректная обработка corner-кейсов

• Обеспечение интуитивной доступности функций

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

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

Возрождение персонального ПО

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

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

• Заботятся о мельчайших деталях

• Уделяют внимание user experience

• Учитывают corner-кейсы

• Создают по-настоящему самостоятельные продукты

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

Вместо заключения

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

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

При разумном использовании ИИ может помочь нам в этом. Но именно нам предстоит определить, что значит «лучше» и как этого добиться.

А какой у вас был опыт с разработкой при помощи ИИ? Буду рад услышать ваши истории и мнения в комментариях.

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.