Разбираем реальные вызовы AI-разработки: смещение узких мест, выбор модели, архитектура агентов и безопасность. Практические советы для разработчиков.
На конференции AI Engineer World's Fair в Сан-Франциско царила атмосфера энтузиазма, но не хайпа. Доклады были сосредоточены на прагматичном решении задач. Индустрия наконец переходит от шумихи вокруг моделей к обсуждению реальных «работ, которые нужно сделать». Но что это значит для разработчика? Как не попасть в ловушку бесконечной генерации кода и не стать жертвой «магических» AI-решений? Разберём ключевые инсайты сообщества.
Мы часто говорим, что AI позволяет генерировать бесконечное количество кода. Но сообщество быстро указало: сырой объём — это метрика тщеславия. Как заметил Раджу Дандигам: «Узкие места управляют ценностью, а не объём кода. Победят те команды, которые сделают прохождение узких мест дёшевым».
Когда генерация кода становится бесплатной, узкие места смещаются вниз по потоку: архитектурная связность, верификация, код-ревью. Назар Бойко добавил: командный центр разработки полезен только если он подсвечивает текущее ограничение; иначе вы просто построили более быстрый способ смотреть не туда.
Проанализируйте свой пайплайн разработки. Где сейчас реальное узкое место? Если генерация кода ускорена, не забывайте про качество ревью и тестирование. Инвестируйте в автоматизацию проверок, а не только в генерацию.
Почему разработчики по умолчанию используют дорогие фронтьерные модели для тривиальных задач? kingai предложил психологическое объяснение: дефолт к фронтьерной модели — это не хеджирование возможностей, а хеджирование ответственности. Если быстрая модель ошибается — это ваша вина; если огромная модель ошибается — можно свалить на модель.
Чтобы сломать эту привычку, Pon предложил не заставлять пользователей выбирать модель через сложные выпадающие списки. Вместо этого софт должен по умолчанию использовать быстрые дешёвые модели, а эскалацию к более мощной модели запускать только на основе детерминированной проверки структуры вывода, а не самооценки модели.
Настройте роутинг запросов к AI: для простых задач (форматирование, простые ответы) используйте маленькие модели, для сложных — только после проверки, что простая модель не справилась. Это сэкономит бюджет и повысит надёжность.
Структурный сдвиг в сторону трактовки AI-агента как append-only лога событий вызвал острую техническую дискуссию. Хотя модель «лог как состояние» обеспечивает исключительную надёжность, Alice предупредила: лог добросовестно воспроизводит утверждения, а не объективную истину. Если агент записал уверенное событие «файл пуст» без подтверждения инструментом, лог просто закрепляет устойчивую галлюцинацию.
Mateo Ruiz предложил элегантное архитектурное разделение по принципу двойной записи в бухгалтерии: вести реестр утверждений для восстановления состояния, но использовать независимый реестр доказательств (диффы файлов, коды возврата) для верификации в реальном мире.
Если вы строите AI-агента, разделите логи: один для трекинга решений агента, второй — для фактических результатов (результаты вызова API, содержимое файлов). Никогда не доверяйте утверждениям агента без подтверждения из внешнего источника.
Когда вы просите агента реализовать фичу, он неявно выбирает за вас стек библиотек. FrancisTRᴅᴇᴠ указал на серьёзную угрозу безопасности: авторитетная подача модели легко усыпляет бдительность человека-проверяющего, оставляя дверь открытой для typosquatted пакетов или атак на цепочку поставок.
Всегда проверяйте, какие библиотеки устанавливает AI-агент. Используйте allowlist проверенных пакетов. Внедрите автоматическую проверку зависимостей на уязвимости. Никогда не доверяйте агенту выбор библиотек без ручного ревью.
Сообщество DEV не увлекается научно-фантастической мечтой о полностью автономном автопилоте. Разработчики, выигрывающие в этом цикле, применяют базовые оборонительные инженерные принципы: делают входные данные предсказуемыми, создают строгие обвязки для кода, тщательно тестируют выходы.
Это зеркально отражает тон конференции: все видят прогресс, но никто не хочет, чтобы их менеджер, наевшийся AI-хайпа, вернулся с рынка, купив «магические бобы».
Помните: хайп проходит, а инженерные принципы остаются. Применяйте их — и ваши AI-решения будут не модными, а рабочими.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →