70% Completion Trap: финальное испытание 30% для кодирования с помощью ИИ

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

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

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

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

Фасилитатор: От нуля до MVP

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

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

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

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

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

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

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

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

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

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

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

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

интеллектуальный парадокс

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

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

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

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

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

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

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

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

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

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

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

Двухступенчатый режим обратного хода

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

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

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

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

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

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

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

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

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

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

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

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

Проблема 70%" говорит о том, что современные средства кодирования ИИ лучше всего рассматривать именно в этом качестве:

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

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

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

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

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

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

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

2. Модель "Непрерывный диалог"

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

3. Модель "доверяй, но проверяй"

• Генерация начального кода с помощью искусственного интеллекта
• Ручной анализ всех критических путей
• Крайние случаи автоматизированного тестирования
• Проводите регулярные аудиты безопасности

Заглядывая в будущее: каково реальное будущее ИИ?

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

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

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

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

1. Начните с малого
   • Используйте ИИ для отдельных, четко определенных задач
   • Просмотрите каждую строку сгенерированного кода
   • Постепенное наращивание функциональности
2. Сохранение модульности
   • Разбейте все на небольшие, целенаправленные документы
   • Поддерживайте четкие интерфейсы между компонентами
   • Документирование границ вашего модуля
3. Доверьтесь своему опыту.
   • Используйте ИИ для ускорения, а не для замены суждений
   • Вопрос о генерации кода, который кажется неправильным
   • Поддерживайте свои инженерные стандарты

Возвышение агентской программной инженерии

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

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

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

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

От реагирования к сотрудничеству

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Демонстрация ловушек качества

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

Я убедился в этом на собственном опыте:

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

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

Утраченное искусство украшения

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

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

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

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

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

• Гордятся своим мастерством
• Внимание к мелким деталям
• Сосредоточьтесь на полноценном пользовательском опыте
• Создан для работы с крайними случаями
• Создание подлинного опыта самообслуживания

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

подчеркнуть

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

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

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