tekBlueprint

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

Введение

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

Когда-то давно, написание кода было преимущественно в текстовом редакторе (я про времена *ASM, C). Но это совсем далеко и можно пропустить.

Потом начали появляться IDE с визуальными конструкторами форм и генераций кода на основе настройки в редакторе ( например, платформа Eclipse с россыпью всяких студий). В 90-х и начале 2000-х визуальные среды разработки, такие как Visual Basic, Delphi и Borland C++ Builder, позволяли создавать быстро приложения. Помимо них были и специализированные студии для работы с серверами приложений. Однако по мере роста сложности проектов появилась проблема “магического” кода, который генерировался автоматически, но был трудно читаемым и поддерживаемым. И это правда, намучился в своё время с IBM WebSphere Application Server Developer Tools for Eclipse.

Потом был переход к более прозрачным подходам, таким как Spring Boot и Ruby on Rails, где конфигурация стала снова текстовой и понятной (YAML, JSON). Эти фреймворки предлагали “соглашения вместо конфигурации” (Convention over Configuration), что упрощало разработку, но при этом сохраняло контроль над кодом.

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

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

Не пишем код, а описываем задачу

Наверное не новость, что сейчас большинство инструментов для работы с AI в разработке, это по большому счёту текстовые чаты. Либо как расширения в IDE или как самостоятельные приложения CLI. Большая часть взаимодействия уже происходит в текстовом виде. Визуальная часть естественным образом отпала. Судя по тому, что вижу, текущие нарративы нацелены на утверждениях, что код-то писать больше не нужно. Для этого есть AI, которому нужно просто правильно поставить задачу. При чём довольно активно и слаженно это продвигается в последние месяцы. Появился новый подход в разработке Spec-Driven Development (SSD) и фреймворки под него OpenSpec, Spec Kit для популярных агентов CLI и плагинов.

Spec-Driven Development (SSD) представляет собой новый подход в разработке. Вместо того чтобы заниматься написанием кода напрямую, от разработки теперь требуется создание точных и детализированных спецификаций, которые затем преобразуются в код с помощью AI. Если рассмотреть более детально, что предлагают, то задача разработки чего-либо разбивается на несколько шагов:

1. Описание правил кодирования в проекте, технического стека проекта (человек или AI).
2. Постановка бизнес-требований – ФТ/НФТ (человек).
3. Построение высокоуровневого плана разработки (AI).
4. Декомпозиция задач из плана (AI).
5. Реализация кода (AI).

На практике SSD работает следующим образом: разработчик создает спецификацию в структурированном формате (часто используя Markdown), которая описывает функциональные и нефункциональные требования к системе. Эта спецификация затем передается AI-агенту, который анализирует ее и генерирует соответствующий код. Процесс итеративный: если результат не соответствует ожиданиям, спецификация уточняется и процесс повторяется.

Человек по сути остаётся только на шаге постановки требований. Во всех остальных шагах выступает в качестве ревьювера и оператора “Однорукого бандита”:

• Дёрнул за рычаг.
• Посмотрел, что выпало.
• Если не повезло, то потерял часть денег за генерацию, подправил запрос и заново на шаг 1.

Думаю, одним плюсов этого подхода является возможность быстрого прототипирования (PoC, MVP). Вместо того чтобы тратить дни или недели на создание базовой структуры приложения, можно получить работающий прототип за несколько часов. Это очень сильно помогает при разработке MVP или при проверке гипотез. Однако есть и обратная сторона: чем выше уровень абстракции, тем сложнее понять, как именно работает сгенерированный код.

Глядя на это, есть ещё некоторый эффект дежавю, если сравнивать с tekBlueprint.plans, tekBlueprint.infra, tekBlueprint.specs, tekBlueprint.kbase. Идея у меня схожая – выстраивания общего пайплайна формирование технических решений для последующей разработки, только на уровне выше. Но комьюнити оказалось быстрее :)

Что с текущими инструментами разработки?

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

• Для AI не требуются визуальные редакторы, фреймворки и платформы. AI может не только генерировать код на основе спецификаций, но и создавать полноценные пользовательские интерфейсы, адаптированные под конкретные требования. Это делает визуальные конструкторы избыточными, к тому же AI не ограничен никакими рамками фреймворков.
• Многие специализированные фреймворки, особенно те, что решают узкоспециализированные задачи, могут стать менее востребованными. AI может создавать альтернативные решения “с нуля” на основе современных подходов разработки и библиотек. Например, вместо использования Tailwind CSS для стилизации, AI может сгенерировать кастомные стили, оптимально подходящие под конкретный проект. Или сам сгенерировать сущности для ORM по базе без внешних инструментов. Видимо выживут только самые популярные и базовые, а остальные уйдут в закат :)
• Традиционные IDE такие, как IntelliJ IDEA или Visual Studio могут стать по большей части только платформами для взаимодействия с AI. Вместо того чтобы предоставлять множество плагинов и инструментов, они превратятся в интерфейсы для управления AI-агентами, которые выполняют большую часть работы по написанию и поддержке кода.
• Для AI не нужны дополнительные анализаторы кода с удобным представлением структуры, он сам это делает. Может выполнить ревью кода, дать подсказки по проблемам и сам же их исправить. Думаю, ревью кода через AI это как раз одна из самых полезных вещей, если получится реализовать без ложных срабатываний.
• Он сам строит планы по декомпозиции задач и сам их выполняет. Выдавая всё представление в человеко-читаемом виде. Автогенерация документации на основе кода и спецификаций может стать стандартом, что сделает многие специализированные инструменты для документации избыточными.
• AI может автоматически генерировать тесты на основе спецификаций и кода. Как пример – Explyt

При этом пытаться соревноваться с AI, у которого фактически знание всего интернета обновляемое в реальном времени, задача амбициозная. Если требуется новая фича или подход, то в инструменте с AI появляется просто из описания этой фичи или подхода в самом проекте (rules, commands, AGENTS.md и прочее). Без просьб к разработчикам, ожидания релиза и так далее.

Уже есть вполне неплохие агенты для разработки (Open Source), почти все из них регулярно использую:

1. Qwen Code
2. Gemini CLI
3. OpenСode
4. Codex
5. Всякие плагины под VSCode (Roo Code, Kilo Code, CLINE, Continue и прочие)

Видимые риски

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

Вытекающая из предыдущего пункта проблема. AI-модели имеют ограничения по объему контекста, который они могут обработать за один раз. Модель может “забыть” важные детали при генерации кода для отдельных компонентов. То есть AI должен динамически подгружать и держать в “голове” необходимый для решения текущей задачи контекст проекта. Как это решать – вопрос открытый, так как большие контексты здесь не помогут. На них модели теряют фокус внимания и начинают ошибаться. Только каким-то образом делить на небольшие подзадачи со сжатием контекста (саммаризация) с предыдущих шагов, которые AI может использовать для сохранения общего понимания архитектуры.

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

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

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

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

Подозреваю, не всем понравится быть операторами AI. Вижу, что у части из них есть вера, что этот навык будет ценен и они не пропадут. Только не очень понятно, почему он будет ценен. Все шаблоны рано или поздно опишут в публичные базы знаний, подходы формализуют в фреймворках, постановки задач тоже. Скорее всего сам AI научат ставить задачи и контролировать выходной результат через цепочки специализированных моделей. Что сейчас и делают, например, для цензурирования чатов. В чем ценность-то останется? Просто недорогой специалист работающий по скрипту, как в call-центрах. Как пример, техкарты у поваров с граммовками и шагами. Достаточно базовых знаний, с какой стороны плита включается и точное следование инструкции, чтобы всё получилось как нужно.

Будущее

В общем, видятся некоторые развилки.

Оптимистичная

AI успешно справляется со всеми задачами по разработке, включая понимание контекста, генерацию качественного кода и его поддержку. Разработчики переходят к роли “архитекторов решений”, которые создают спецификации и контролируют работу AI. Большинство традиционных инструментов разработки становятся ненужными и уходят в историю. Появляются новые специализированные инструменты для управления AI-агентами и создания спецификаций. Компании получают возможность разрабатывать сложные системы с меньшими затратами и быстрее выводить их на рынок. Качество кода остается высоким благодаря постоянному обучению AI на лучших практиках и обратной связи от сообщества.

Более реалистичная и обобщённая

AI успешно справляется с рутинными задачами, но для сложных и уникальных решений требуется участие человека. Разработчики используют AI для генерации базовой структуры кода, но затем вручную дорабатывают и оптимизируют его. Появляются гибридные инструменты, которые сочетают возможности AI с традиционными подходами к разработке. Многие традиционные инструменты исчезают или подстраиваются, интегрируя AI-функционал. Качество кода поддерживается за счет комбинации автоматической генерации и ручной проверки. Этот сценарий наиболее вероятен в среднесрочной перспективе, так как он позволяет извлечь преимущества AI, сохраняя контроль над основными аспектами разработки.

Реалистичная и эффективная, как мне кажется

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

Маловероятная

AI показывает низкую эффективность в долгосрочной перспективе и его использование сокращается до минимума. Думаю, шансов не много, слишком много ресурсов в это вложено, инвесторы не простят такого :)

Заключение

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