Конец эры разработчиков приложений: почему следующие 10 лет за создателями AI-агентов

Title: Эпоха инженеров ИИ-агентов Excerpt: Мы покидаем эпоху Интерфейсов и вступаем в эпоху Агентов. В ближайшее десятилетие самым ценным титулом будет не «Фулстек-разработчик», а «Инженер ИИ-агентов».

У истории есть забавная привычка повторяться, и обычно это происходит именно тогда, когда мы начинаем чувствовать себя комфортно.

Представьте конец 90-х. Если вы умели укрощать HTML и заставлять Perl или PHP работать в связке, создавая функционирующий сайт, вы были волшебником. Вы были веб-инженером, и весь мир был у ваших ног. Вы строили витрины интернета.

Перенесемся в 2009 год. iPhone только что перевернул мир. Внезапно всем стало наплевать на ваш статический сайт. Энергия сместилась в сторону Objective-C и Java. Если вы были разработчиком мобильных приложений, вы писали будущее. Вы создавали инструменты, которые люди носили в своих карманах.

А теперь посмотрите на 2024 год. Воздух снова кажется разреженным и статичным. Магазины приложений перенасыщены, веб переполнен. Но под поверхностью происходит тектонический сдвиг. Мы покидаем эпоху Интерфейсов и вступаем в эпоху Агентов.

В ближайшее десятилетие самым ценным титулом будет не «Фулстек-разработчик» (Full Stack Developer) и не «iOS-инженер». Им станет Инженер ИИ-агентов (AI Agent Engineer).

Новый тектонический сдвиг

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

Последние двадцать лет разработка программного обеспечения заключалась в создании четких, детерминированных путей, по которым кликали люди. Вы создавали кнопку; человек нажимал её; код выполнял функцию. Человек был мозгом, программа — мускулами.

Эта динамика переворачивается.

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

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

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

Демистификация магии: Инструменты и Контекст

Когда люди слышат «ИИ-агент», они представляют себе Скайнет или какую-то невероятно сложную архитектуру нейронных сетей. Давайте отбросим лишний шум.

Создание агента — это не магия. Это инженерия. И она сводится к двум вещам: Инструменты (Tools) и Контекст (Context).

Я заметил, что большинство разработчиков слишком всё усложняют. Они думают, что им нужно тренировать модели. Не нужно. Модели — Claude, GPT-4, Llama — уже достаточно умны. Ваша задача — дать им руки и память.

1. Инструменты (Даем модели руки)

Большая языковая модель (LLM) — это просто мозг в колбе. Она может думать, но не может прикоснуться к миру. «Агент» — это просто LLM, которой дали доступ к API-эндпоинтам или командам CLI.

Вы говорите модели: «Вот инструмент под названием list_files. Вот инструмент read_file. А вот инструмент send_email».

2. Контекст (Даем модели направление)

Затем вы определяете роль. «Ты — старший QA-инженер. Твоя цель — исправить ошибки типов в этом репозитории».

Вот и всё. Это основной цикл.

Если вы использовали Cursor или Claude Code, вы видели это в действии. Вы не занимаетесь микроменеджментом правок. Вы говорите: «Исправь ошибки типов в utils.ts».

Агент думает: Окей, сначала мне нужно увидеть файл. Он решает использовать инструмент ls. Затем он решает использовать grep или read. Он находит ошибку. Он решает написать исправление. Он запускает компилятор, чтобы проверить свою работу.

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

От чат-ботов к движкам принятия решений

Последние два года мы застряли в фазе «Чата». Мы относимся к ИИ как к умному библиотекарю — задаем вопрос, он дает ответ.

Эта фаза заканчивается.

Агентная фаза — это про исполнение. Это взгляд на CLI (командную строку) не как на место, где печатаете вы, а как на игровую площадку для модели.

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

Сегодня я могу написать агента. Я даю ему доступ к Stripe API (Инструмент) и нашей истории переписки (Контекст). Я даю ему политику: «Сделать возврат, если пользователь недоволен в течение 7 дней». Агент читает входящее письмо, решает, соответствует ли оно критериям, запускает инструмент возврата в Stripe и составляет ответ.

Никакого UI. Никакой очереди тикетов в поддержку. Только цель и набор инструментов.

«Сложная середина» создания агентов

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

Традиционное программирование логично. Если X, то Y. Оно либо работает, либо ломается.

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

Именно здесь лежит новый набор навыков.

Быть инженером агентов — это не просто писать скрипты на Python. Это про:

• Промпт-инжиниринг как архитектуру: Проектирование системных промптов для ограничения поведения модели.
• Eval Driven Development (Разработка через оценку): Вы не можете написать юнит-тесты для креативности, поэтому вы строите пайплайны оценки, чтобы измерить, как часто агент успешно справляется с задачей.
• Дизайн инструментов: Создание API-интерфейсов, которые достаточно «чисты», чтобы модель могла их понять и не запутаться.

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

Практические выводы: С чего начать сегодня

Если бы я начинал с нуля сегодня или хотел сменить вектор карьеры, вот что бы я сделал:

1. Перестаньте создавать GUI: По крайней мере, для своих пет-проектов. Попробуйте решить проблему без фронтенда. Можете ли вы решить её с помощью CLI и LLM?
2. Изучите протокол интерфейса: Поймите, как работает вызов функций (function calling) в OpenAI или использование инструментов (tool use) в Anthropic. Это TCP/IP эпохи агентов.
3. Создайте «Делателя», а не «Болтуна»: Не делайте бота, который отвечает на вопросы о вашем календаре. Создайте бота, который управляет вашим календарем. Дайте ему возможность удалять события. Почувствуйте страх, давая ИИ права на запись. Именно в этот момент вы начинаете по-настоящему учиться.
4. Освойте управление контекстом: Научитесь запихивать нужную информацию в контекстное окно, не переполняя его. RAG (Retrieval-Augmented Generation) — это только начало.

Возможности впереди

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

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

Десять лет назад вас нанимали писать код. Сегодня вас нанимают архитектором системы, которая пишет код.

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

За дело.