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

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

На практике, похоже, приходится выбирать.

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

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

Это не два способа достижения одной цели.

Это две разные стратегии разработки.

Стратегия первая: нужно быстро

Представим обычную ситуацию.

Есть новый рынок, появилась возможность, конкурент ещё не успел занять нишу. Основная ценность проекта заключается в скорости выхода.

В такой ситуации ИИ действительно способен радикально изменить разработку.

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

Но здесь важно сразу принять ограничение этого подхода.

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

Главным объектом проверки становится результат.

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

Если да — продукт можно использовать.

При этом совершенно не обязательно разбираться, каким именно образом агент реализовал каждую функцию внутри.

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

Получается довольно радикальное правило:

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

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

Быстрый режим не означает высокое качество

Здесь важно не обманывать себя.

Если продукт создавался в первую очередь ради скорости, качество приходится оценивать снаружи.

Мы можем проверить, что он делает нужное.

Мы можем проверить основные сценарии.

Мы можем протестировать критические функции.

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

Чтобы делать такое утверждение, нужно эту архитектуру понимать.

А понимание требует времени.

Поэтому быстрый AI-first режим — это в определённом смысле ставка.

Мы сознательно обмениваем часть внутреннего контроля на скорость производства.

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

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

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

ИИ пишет код, но не передаёт понимание

В обычной разработке написание кода и накопление знания о системе происходят почти одновременно.

Программист проектирует компонент, пишет его, исправляет ошибки, видит зависимости, меняет архитектуру.

В результате код появляется не отдельно от понимания — понимание формируется непосредственно во время его создания.

С ИИ эта связь разрывается.

Агент может за несколько часов создать десятки файлов, несколько подсистем и большое количество связей между ними.

Человек при этом знает только то, какие задачи он ставил агенту.

Это принципиально разные виды знания.

Человек может знать, что система должна делать, но не знать, почему она устроена именно так.

ИИ производит код, но знание, которое возникло в процессе его производства, автоматически в голову человека не переносится.

Это похоже на парное программирование

Представим двух разработчиков примерно одинакового уровня.

Они вместе обсуждают архитектуру, пишут код, проверяют решения друг друга.

Через некоторое время оба более-менее понимают продукт изнутри.

Теперь представим, что один специалист значительно сильнее и работает намного быстрее второго.

Тогда происходит одно из двух.

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

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

Либо сильный продолжает работать в своём темпе.

Тогда через некоторое время второй перестаёт понимать значительную часть проекта.

С ИИ это расхождение происходит намного быстрее.

Агент способен производить код быстрее, чем человек способен его читать и осмысливать.

Поэтому человек должен выбрать:

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

Менеджер агента — не второй программист

Очень часто разработчик, использующий AI-агента, перестаёт играть роль второго программиста.

Он становится менеджером.

Он говорит:

• «Добавь такую функцию»;
• «Переделай интерфейс»;
• «Исправь ошибку»;
• «Упрости эту подсистему»;
• «Добавь поддержку ещё одного сценария».

После этого он смотрит на результат и ставит следующую задачу.

Это действительно позволяет двигаться очень быстро.

Но менеджер проекта и разработчик системы обладают разным знанием.

Менеджер знает состояние задач.

Разработчик знает состояние кода.

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

Необходимо сначала восстановить огромное количество потерянного контекста.

Вторая стратегия: нужен надёжный и управляемый продукт

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

Здесь уже нельзя позволять ИИ далеко уходить вперёд.

Нужно двигаться небольшими этапами.

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

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

Это тоже может заметно ускорить разработку.

ИИ снимет много механической работы, поможет писать типовые части, тесты, миграции, интеграции.

Но ожидать здесь десятикратного ускорения уже гораздо сложнее.

Потому что ограничителем становится не скорость генерации кода.

Ограничителем становится скорость человеческого понимания.

Это важно учитывать ещё до начала проекта

Отсюда следует неприятный практический вывод.

Если бизнес-план проекта выглядит примерно так:

«Раньше это заняло бы полгода, но с ИИ мы сделаем за месяц и успеем попасть в тренд»,

то нельзя одновременно строить процесс так, будто команда собирается тщательно понимать и контролировать каждое внутреннее решение.

Эти требования начинают конфликтовать.

Если через две недели после начала такого проекта команда решит:

«Теперь давайте внимательно разберём архитектуру и приведём всё к высокому инженерному стандарту»,

может выясниться, что преимущество по времени исчезло.

Потому что придётся оплачивать отложенное понимание.

Часто — с процентами.

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

Особенно опасно пропускать ранние архитектурные ошибки

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

Архитектурные ошибки нужно ловить очень рано.

Потому что ИИ обладает одной особенностью: он невероятно быстро материализует последствия принятого решения.

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

ИИ может построить вокруг неё десятки тысяч строк очень быстро.

Через некоторое время первоначальная ошибка уже размазана по множеству компонентов и зависимостей.

Исправить её локальным изменением становится сложно.

Начинается цепочка:

• исправили одну часть;
• сломалась другая;
• добавили совместимость;
• появилась ещё одна ветка;
• добавили специальный случай;
• появился новый обработчик состояния.

Количество кода растёт, но система не обязательно становится правильнее.

Почему поздний рефакторинг с помощью ИИ особенно сложен

В этот момент возникает соблазн сказать агенту:

«Упрости эту часть».

На практике такая постановка часто оказывается слишком неопределённой.

Человеку кажется очевидным, что именно означает «эта часть».

Но система может состоять из нескольких взаимосвязанных подсистем.

Возникают вопросы:

• Какие связи необходимо сохранить?
• Что является случайной сложностью?
• Что является частью бизнес-логики?
• Как далеко разрешено распространить изменение?
• Что именно означает «упростить»?

Агент может оставить слишком много.

Или, наоборот, убрать слишком много и разрушить функции, которые человек вообще не считал относящимися к рефакторингу.

Особенно опасно, если сам человек уже не понимает проект полностью.

Тогда возникает парадокс:

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

Иногда нужно не рефакторить, а переписывать

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

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

Возможно, дешевле провести анализ продукта на более высоком уровне.

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

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

Он мог прекрасно решить первоначальную задачу.

Просто его экономическая жизнь закончилась.

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

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

В итоге выбор довольно простой

Если главная цель — скорость, нужно использовать скорость ИИ по-настоящему.

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

Если главная цель — качество, надёжность и управляемость, работать нужно иначе.

• С самого начала.
• Маленькими шагами.
• Постоянно понимая происходящее.
• Не позволяя агенту создавать объём изменений быстрее, чем человек способен их осмыслить.

Это будет медленнее.

Возможно, значительно медленнее, чем обещает идея «ИИ напишет всё за нас».

Но это цена инженерного контроля.

Поэтому главный выбор при AI-разработке, возможно, нужно делать ещё до первой строки кода:

мы сейчас покупаем скорость или понимание?

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