Было время, когда самой сложной частью создания программного обеспечения было написание самого программного обеспечения.
Сегодня это всё меньше соответствует действительности.
У нас есть лучшие фреймворки, лучшие библиотеки, лучшие API, лучшая облачная инфраструктура, лучшие инструменты разработчика, а теперь ещё и ИИ может сгенерировать за нас значительную часть кода.
И всё же я постоянно вижу один и тот же паттерн:
Мы становимся лучше в создании вещей, но не обязательно лучше в решении о том, что именно стоит создавать.
И, как мне кажется, это становится одной из крупнейших инженерных проблем нашего времени.
Программное обеспечение стало слишком легко начинать
Подумайте, что требуется сегодня, чтобы создать приложение.
Вы можете сгенерировать фронтенд за считаные минуты.
Подключить API.
Добавить аутентификацию.
Добавить базу данных.
Развернуть его.
Добавить ИИ-модель.
Дать модели доступ к инструментам.
Добавить агента.
Добавить ещё один сервис.
Добавить мониторинг.
Добавить очередь.
Добавить векторную базу данных.
Добавить фреймворк оркестрации.
И вскоре у вас оказывается на удивление сложная архитектура.
А иногда вы решили задачу, которая на самом деле не требовала ничего из этого.
В этом заключается парадокс современной разработки программного обеспечения:
Чем дешевле становится создавать программное обеспечение, тем проще становится создавать ненужное программное обеспечение.
ИИ сделал эту проблему ещё больше
ИИ изменил расклад ещё сильнее.
Раньше я мог потратить несколько часов на реализацию одной функции.
Сегодня я могу описать функцию, и ИИ-ассистент по коду сгенерирует большую часть реализации.
Это невероятно полезно.
Но это также устраняет важное трение.
Когда создание чего-либо требовало значительных усилий, сами усилия выступали в роли фильтра.
Вы естественным образом задавались вопросом:
«Стоит ли это вообще создавать?»
Когда реализация становится дешёвой, этот вопрос становится легче проигнорировать.
Вы можете просто построить это.
А потом построить ещё одну версию.
А потом добавить ещё одну функцию.
А потом добавить агента, потому что фреймворк для агентов выглядит интересно.
Стоимость реализации падает.
Но стоимость сложности никуда не исчезает.
Каждая функция создаёт проблему в будущем
Функция редко обходится только в то, что требуется на её создание.
Она также создаёт:
- код, который нужно поддерживать
- баги, которые нужно расследовать
- зависимости, которые нужно обновлять
- документацию, которую нужно поддерживать
- граничные случаи, которые нужно обрабатывать
- пользователей, которых нужно поддерживать
- вопросы безопасности
- соображения производительности
- требования к мониторингу
- решения, которые должны понять будущие разработчики
Именно поэтому функция, написанная за 30 минут, иногда порождает проблему сопровождения на полгода.
Изначальная реализация была дешёвой.
Система стала дорогой.
Это особенно опасно с кодом, сгенерированным ИИ, потому что первоначальная реализация может ощущаться почти бесплатной.
Вы просите о функции.
Код появляется.
Он работает.
Вы двигаетесь дальше.
Через полгода кому-то придётся разбираться, почему от неё зависят семнадцать компонентов.
Сложность — это технический долг, который видно слишком поздно
Разработчики, как правило, хорошо распознают очевидный технический долг.
Плохие имена.
Дублированный код.
Отсутствующие тесты.
Устаревшие зависимости.
Большие функции.
Но существует и другой тип технического долга, который распознать сложнее:
ненужная архитектура.
У вас может быть прекрасно написанный код внутри излишне усложнённой системы.
У вас могут быть отличные абстракции, которые никому не были нужны.
У вас могут быть идеально реализованные микросервисы там, где хватило бы одного приложения.
У вас может быть впечатляющий ИИ-агент там, где детерминированный рабочий процесс был бы безопаснее.
Каждый отдельный компонент может быть технически корректным.
А вся система при этом может быть неправильной.
Я всё больше подозрительно отношусь к «больше»
Больше сервисов.
Больше абстракций.
Больше инструментов.
Больше фреймворков.
Больше автоматизации.
Больше агентов.
Больше интеграций.
Больше дашбордов.
Больше функций.
Больше ИИ.
Ничто из этого не является плохим по своей природе.
Проблема начинается тогда, когда «больше» становится определением прогресса по умолчанию.
Иногда лучшее инженерное решение — что-то удалить.
Удалить зависимость.
Удалить абстракцию.
Удалить сервис.
Удалить шаг с ИИ.
Удалить функцию.
Удалить целый рабочий процесс.
Это может быть труднее, чем что-то добавить.
Потому что добавление демонстрирует активность.
А удаление требует суждения.
Лучшая архитектура может выглядеть скучно
Есть кое-что в хороших системах, что я со временем стал всё больше ценить:
Они могут выглядеть на удивление скучно.
Представьте два решения.
Система A
Пользователь → API → База данных → Ответ
Система B
Пользователь → Шлюз → Сервис A → Очередь → Сервис B → Агент → Маршрутизатор инструментов → Векторная БД → Внешний API → Сервис валидации → Шина событий → Сервис C → База данных → Ответ
Система B выглядит более изощрённой.
Но изощрённость — не то же самое, что качество.
Если обе системы надёжно решают одну и ту же задачу, Система A может быть кардинально лучше.
Не потому, что она использует более новые технологии.
А потому, что в ней меньше вещей, которые могут сломаться.
Именно поэтому я всё больше верю в то, что простота — это не отсутствие инженерии.
Это результат инженерного суждения.
Вот где ИИ-агенты вписываются в этот разговор
Именно поэтому я также стал осторожен в отношении нынешней одержимости ИИ-агентами.
Агенты полезны.
Существуют задачи, где динамическое принятие решений, выбор инструментов, итерации и автономность действительно создают ценность.
Но если задачу может решить детерминированный рабочий процесс, агент может просто привнести дополнительную неопределённость.
Вопрос не должен звучать так:
«Могу ли я превратить это в агента?»
Лучше спросить:
«Требует ли эта задача на самом деле автономного принятия решений?»
Это различие имеет значение.
Я писал об этом подробнее в своей статье «Хватит создавать ИИ-агентов. Начните создавать ИИ-системы».
Общий принцип тот же:
Не оптимизируйте под технологическую изощрённость. Оптимизируйте под результат.
Нам нужен новый инженерный вопрос
Долгое время разработчиков призывали задавать вопрос:
«Как мне это построить?»
Затем мы научились спрашивать:
«Как мне построить это хорошо?»
Я считаю, что есть ещё один вопрос, который нам нужно поставить перед обоими:
«Должно ли это вообще существовать?»
Этот вопрос применим далеко не только к программному обеспечению.
Должна ли существовать эта функция?
Должен ли существовать этот сервис?
Должна ли существовать эта автоматизация?
Должна ли существовать эта база данных?
Должен ли существовать этот компонент с ИИ?
Должно ли существовать всё это приложение?
Иногда ответ будет «да».
Но иногда ответ будет:
Нет.
И это не провал.
Это инженерия.
ИИ делает суждение более ценным, а не менее
Это, пожалуй, самое интересное следствие разработки с помощью ИИ.
Если ИИ продолжит ускорять реализацию, то сама реализация станет менее дифференцирующим фактором.
Ценные навыки смещаются вверх.
Понимание проблемы.
Определение правильных требований.
Выбор правильной архитектуры.
Распознавание ненужной сложности.
Умение понять, когда не стоит автоматизировать.
Умение понять, когда не стоит использовать ИИ.
Понимание компромиссов.
Оценка того, действительно ли что-то работает.
И, возможно, самое важное:
умение понять, что не стоит строить.
ИИ может сгенерировать десять возможных реализаций, прежде чем вы закончите объяснять проблему.
Это делает суждение более важным, а не менее.
Прежде чем вы построите следующую вещь
Я начал обдумывать решения в разработке через гораздо более простой фильтр.
Прежде чем что-то строить, спросите:
- Какую проблему это решает?
Если вы не можете ясно объяснить проблему, остановитесь.
- Кому это на самом деле нужно?
«Кто-то, возможно, этим воспользуется» — недостаточно сильный ответ.
- Какое решение самое простое?
Не самое впечатляющее.
Самое простое.
- Какую сложность это привнесёт?
Думайте за пределами сегодняшней реализации.
- Нужна ли здесь автоматизация?
Возможно, ручной процесс вполне приемлем.
- Нужен ли здесь ИИ?
Возможно, правило, запрос, функция или обычное приложение лучше.
- Что произойдёт, если мы это не построим?
Это вопрос, который, как мне кажется, мы задаём слишком редко.
Иногда ничего не происходит.
И это может быть лучшим исходом.
Парадокс создателя
Мы вступаем в необычный период в разработке программного обеспечения.
Создавать становится невероятно легко.
Но решать, что заслуживает быть созданным, может становиться всё труднее.
Это порождает странный парадокс:
Чем лучше становятся наши инструменты, тем важнее становится сдержанность.
Когда написание кода было дорогим, мы естественным образом избегали ненужного кода.
Когда инфраструктура была сложной, мы естественным образом избегали ненужной инфраструктуры.
Когда разработка программного обеспечения будет всё больше выполняться с помощью ИИ, нам понадобится другое ограничение.
Суждение.
Не всё, что можно построить, заслуживает существования.
Не каждый рабочий процесс нуждается в автоматизации.
Не каждому приложению нужен ИИ.
Не каждому ИИ-приложению нужен агент.
И не каждая техническая проблема нуждается в техническом решении.
Возможно, следующий великий навык разработчика — не умение строить быстрее.
Возможно, это умение посмотреть на проблему и уверенно сказать:
«Нам не нужно это строить».
А что думаете вы?
Становятся ли разработчики лучше в создании программного обеспечения или просто лучше в создании его в больших объёмах?
Примечание: Ищете более глубокое понимание будущего искусственного интеллекта? Загляните в ReThynk AI, чтобы получить доступ к нашим последним исследованиям, статьям журнала и ресурсам для разработчиков. Нажмите здесь