Проблема 70%: суровые истины о программировании с помощью ИИ

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

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

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

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

Бутстрапперы: от нуля до MVP

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

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

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

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

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

• Используют ИИ для дополнения кода и создания предложений
• Используют ИИ для решения сложных задач рефакторинга
• Генерации тестов и документации
• Используют ИИ в качестве «парного программиста» для решения проблем

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

Скрытая стоимость “ИИ скорости”

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

• Рефакторят сгенерированный код в более мелкие, сфокусированные модули
• Добавляют обработку крайних случаев, пропущенных ИИ
• Усиливают определения типов и интерфейсов
• Подвергают сомнению архитектурные решения
• Добавляют комплексную обработку ошибок.

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

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

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

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

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

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

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

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

• Быстрого прототипирования идей, которые они уже понимают
• Генерации базовых реализаций, которые затем можно доработать
• Изучения альтернативных подходов к решению известных проблем
• Автоматизации рутинных задачи программирования

В то же время младшие инженеры часто:

• Принимают неправильные или устаревшие решения
• Упускают важные аспекты безопасности и производительности
• Сталкиваются с трудностями при отладке кода, созданного искусственным интеллектом
• Создают хрупкие системы, которые не до конца понимают.

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

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

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

Два шага назад

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

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

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

Парадокс обучения продолжается

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

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

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

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

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

1. Использовали ИИ для быстрого прототипирования
2. Тратили время на то, чтобы понять, как работает сгенерированный код
3. Изучали  базовые концепции программирования параллельно с использованием ИИ
4. Постепенно создавали фундамент знаний
5. Использовали ИИ как инструмент обучения, а не просто генератор кода

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

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

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

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

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

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

Что на самом деле работает: практические примеры

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

1. Модель «первый черновик»

• Позвольте ИИ сгенерировать базовую реализацию
• Вручную просмотрите и отрефакторите код для повышения модульности
• Добавьте комплексную обработку ошибок
• Напишите подробные тесты
• Задокументируйте ключевые решения

2. Модель «постоянный разговор»

• Запустите новые чаты с ИИ для каждой отдельной задачи
• Контекст должен быть сфокусирован и минимален
• Часто просматривайте и фиксируйте изменения
• Поддерживайте тесную обратную связь

3. Модель «Доверяй, но проверяй»

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

Заглядывая в будущее: реальные перспективы ИИ?

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

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

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

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

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

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

2. Оставайтесь модульными

• Разбейте все на небольшие, целенаправленные файлы
• Поддерживайте четкие интерфейсы между компонентам
• Документируйте границы модулей

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

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

Расцвет агентной разработки

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

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

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

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

От ответчиков к совместной работе

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

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

• Проактивно выявлять потенциальные проблемы
• Запускать и выполнять наборы тестов
• Проверять элементы пользовательского интерфейса и делать скриншоты
• Предлагать и внедрять исправления
• Проверять работоспособность решений (это может быть очень важно).

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

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

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

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

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

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

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

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

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

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

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

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

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

• Более сильные системный дизайн и архитектурное мышление
• Лучшая спецификация требований и коммуникация
• Большее внимание обеспечению качества и проверке
• Усиленное взаимодействие между людьми и искусственным интеллектом

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

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

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

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

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

• Сообщения об ошибках, которые не имеют смысла для обычных пользователей
• Краевые случаи, приводящие к краху приложения
• Запутанные состояния пользовательского интерфейса, которые никто не расчистил
• Доступность полностью игнорируется
• Проблемы с производительностью на медленных устройствах

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

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

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

• Зацикленность на сообщениях об ошибках
• Тестирование на медленных соединениях
• Грациозная обработка всех внешних ошибок
• Создание функций доступными для обнаружения
• Тестирование с реальными, часто нетехническими пользователями.

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

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

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

• Гордятся своим ремеслом
• Заботятся о мелких деталях
• Фокусируются на всем пользовательском опыте
• Создают продукты, которые не имеют аналогов
• Создают действительно самоподдерживаемые сервисы

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

Итог

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

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

Источник