Site icon AppTractor

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

AppTractor

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

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

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

Я наблюдаю две различные модели того, как команды используют ИИ для разработки. Назовем их «бутстрапперы» и «итераторы». Обе эти модели помогают инженерам (и даже нетехническим пользователям) сократить промежуток времени от идеи до реализации (или 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%» говорит о том, что нынешние инструменты для ИИ-программирования лучше всего рассматривать как:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

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

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

Источник

Exit mobile version