Новый LAMP, или почему ваш Agent Pipeline — это Apache в 2006 году

Помните LAMP? Linux, Apache, MySQL, PHP. 2006 год. Резюме сисадмина без LAMP не рассматривали. Курсы, сертификаты, форумы. Все учили стек. Мало кто спрашивал: а задачу-то как решать? Стек и есть решение. Поставил LAMP, залил WordPress, работает. Следующий.

Откройте Хабр в 2026. “Собираем RAG на PHP за вечер.” “Оркестрация LLM через Redis.” “Agentic RAG Challenge.” “Multi-agent pipeline с LangChain.” На Coursera уже есть курс “Applied Agentic AI Pipelines”. Gartner фиксирует рост запросов по мультиагентным системам на 1445%.

LangChain, RAG, VectorDB, Tool Calling. Новый LAMP.

Все учат стек. Мало кто спрашивает: а задачу-то как решать?

Сто тридцать один коммит за одиннадцать дней. Firmware для STM32, криптодвижок с ECDSA, пересборка BSP для ARM64. Без LangChain. Без RAG. Папка с файлами и git.

Я четыре месяца работаю иначе. Больше четырёхсот сессий, одиннадцать проектов, firmware для STM32, криптодвижок, пересборка BSP для ARM64. Без LangChain. Без RAG. Без vector database. Модель беру по API, если надо, могу поставить локально. Это деталь. Фишка в другом. В том числе в том, почему при таком подходе тебя невозможно заменить.

Что строят все

Типичный Agent Pipeline выглядит так. Оркестратор принимает задачу. Раздаёт её агентам: один пишет код, другой ревьюит, третий тестирует. Агенты ходят в RAG за контекстом, дёргают tools, возвращают результат. Человек нажимает кнопку и ждёт.

Стек: LangChain или LangGraph для оркестрации. Pinecone или Chroma для векторов. Embeddings от OpenAI или Cohere. Tool calling через function schemas. Observability через LangSmith. Деплой в Docker. Мониторинг в Grafana.

Звучит солидно. Компании не обучают свои модели, это дорого. DeepSeek заявил что потратил около шести миллионов долларов на compute для обучения V3, хотя реальные затраты на инфраструктуру и R&D на порядки выше. Реальный паттерн: берут Llama, Qwen или API от Anthropic, обвязывают инфраструктурой. Вся “магия” в обвязке.

Проблема в том, что обвязка решает инфраструктурную задачу. Как доставить контекст модели. Как оркестрировать вызовы. Как хранить embeddings. Это важно. Но это не про то, как решать задачу пользователя.

Если присмотреться, большинство “агентных конвейеров” в продакшене делают одно: следят за кодом. Code review бот, тест-раннер с AI, линтер на стероидах. Полезно. Но это не “агент пишет код”. Это “агент проверяет код, который написал человек”. Когда пытаются сделать чтобы агент реально писал, получается Copilot Workspace. Все строят инфраструктуру доставки: как доставить контекст модели. Никто не строит инфраструктуру знания: какой контекст доставлять и почему.

LAMP тоже решал инфраструктурную задачу. Как поднять сервер. Как подключить базу. Как отдать PHP-страницу. А потом пришёл highload, и оказалось что LAMP это фундамент, а не архитектура. Для архитектуры нужно думать про кэширование, шардирование, очереди, паттерны отказоустойчивости. Стек не спасает. Но индустрия продолжает его учить. Почему? Два механизма. Первый: инерция. AI это “чат в браузере” или “плагин в IDE”. Мысль “а что если .md файлы и git” просто не приходит в голову. Нет триггера. Если ты ведёшь один проект, потеря контекста между чатами раздражает, но терпимо. Если одиннадцать, терпеть нечем. Второй: сложность как ценность. Чем сложнее стек, тем “профессиональнее”. Простое решение кажется несерьёзным. В 2006 те кто использовал nginx вместо Apache считались чудаками. Через пять лет nginx стал стандартом.

С агентами то же самое. Pipeline это фундамент. Для реальной работы нужно думать про организацию знания.

Вот конкретный пример. GitHub Copilot Coding Agent. Назначаешь issue на Copilot, он читает репозиторий через semantic search, строит план, пишет код, открывает draft PR. Ты ревьюишь. Звучит как будущее.

На практике: Austin Henley, исследователь в области developer tools, написал про Copilot Workspace что UX “entirely wrong”, пять минут на однострочное изменение, сгенерированный код часто багованный или вообще не имеет отношения к спецификации. Самая популярная дискуссия в GitHub Community за последний год: просьба дать возможность заблокировать Copilot от генерации issues и pull requests в репозиториях.

Посмотрите на типичный агентный pull request. Восемьсот слов описания. Пять секций: что, зачем, почему безопасно, edge cases, тесты. Идеальный технический документ. Рядом человеческий PR на ту же кодовую базу: две строки “зачем”, три строки “что изменилось”, видео. Разговорный тон. Бот тщательнее. Бот аналитичнее. Бот не помнит прошлого PR. Следующая задача для него это чистый лист. Контекст не передаётся. Они решают проблему “как агент сделает одну задачу”. Вопрос “как вести проект месяцами” даже не стоит.

Почему так? Потому что тикет прилетает в чат, агент ищет по коду, но у него нет истории решений. Нет понимания почему сделали так, а не иначе. Нет компетенций по домену. Нет контекста предыдущих сессий. Каждый тикет с нуля. Semantic search по коду это не понимание проекта. Это grep с embeddings.

Что строю я

У меня нет оркестратора агентов. Нет RAG. Нет vector database. Есть папка с файлами и git. Серьёзно.

Но внутри этой папки есть система. Сессии, роли, компетенции, контексты, контракты, маршрутизация. Каждый элемент решает конкретную проблему, с которой я столкнулся в реальной работе.

Модель это деталь. Сегодня Claude, завтра что-то другое. Если надо поставить локально, поставлю. Если надо сделать агента для конкретной задачи, сделаю. Но агент без организованного знания это чат с нуля. Каждый раз.

Разница между моим подходом и Agent Pipeline не в технологии. Она в вопросе.

Pipeline спрашивает: “как сделать так, чтобы агент работал без меня?” Я спрашиваю: “как сделать так, чтобы я с агентом мог больше?”

Робот заменяет человека. Экзоскелет усиливает. Я строю экзоскелет.

Сессии: почему чат это не единица работы

Обычный workflow с AI: открыл чат, написал промт, получил ответ, закрыл. Завтра открыл новый чат. Контекст потерян. Решение, принятое вчера, недоступно. Каждый раз с нуля.

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

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

Это не четыреста чатов. Это цепочка, где каждое звено знает про предыдущее.

Чат это SMS. Сессия это рабочий журнал.

Роли и компетенции: почему промт “ты программист” не работает

Все знают про system prompt. “Ты опытный Python-разработчик. Пиши чистый код.” Это уровень ноль. Модель кивает и пишет что-то среднее.

Есть промежуточный уровень. Cursor Rules, Agent Skills из маркетплейса. На GitHub лежит awesome-cursorrules, есть cursor.directory, vibecodekit.dev. Скачал файл с правилами для Flutter или React, подключил, агент стал чуть лучше. Один разработчик на Medium написал прямо: “Stop Engineering Prompts, Start Engineering Context”. Другой потратил день, портируя свои .cursorrules из Cursor в Claude Code, потом в Cline, потом в Copilot. Четыре одинаковых файла в четырёх разных форматах.

Проблема в том, что это чужие правила для generic задач. “Используй tabs.” “Пиши тесты.” “Следуй SOLID.” Полезно? Да. Но это как скачать чужой .vimrc с GitHub. Чужие привычки, не твои решения. Нет контекста проекта. Нет истории: почему в этом проекте мы используем PKCS11, а не PKCS7. Нет рефлексии: какие ошибки агент уже делал и как их избежать.

Роль в моей системе это другое. У роли есть компетенции, у компетенций навыки. У проекта есть набор ролей: аналитик, архитектор, кодер, тестировщик. У каждой роли свои компетенции. Компетенция это не “умеет писать на Python”. Компетенция это файл, который описывает: какие API использовать, какие паттерны, какие ограничения железа, какие ошибки типичны для этого домена.

Конкретный пример. Есть проект: CAN-FD адаптер на STM32. Роль: firmware-coder. Компетенции: STM32 HAL API, FDCAN peripheral, USB HID protocol, DLC handling, типичные ошибки при работе с dual-channel CAN. Эта компетенция выросла из десятков сессий реальной работы с железом. Из документации, форумов, даташитов, граблей при отладке и практики.

Когда агент получает эту роль с компетенциями, он перестаёт галлюцинировать про несуществующие регистры. Перестаёт путать FDCAN с bxCAN. Знает что DLC в CAN-FD кодируется нелинейно. Потому что всё это описано в компетенции.

“Модель плохо пишет код”. Частая претензия. Ответ: модель пишет код ровно настолько хорошо, насколько ты умеешь объяснить что писать. Промт “ты программист” это как сказать хирургу “ты врач, оперируй”. Без снимков, без анамнеза, без протокола. Компетенция это снимки, анамнез и протокол в одном файле.

Результат? USB HID DFU bootloader. TRNG на аппаратном генераторе. ECDSA P-256. Девяносто девять тестов на PKI. Всё это с агентом, которому дали правильную роль и компетенции. Не автономным агентом. Напарником.

Контексты и маршрутизация: как не потеряться в одиннадцати проектах

Один проект, ещё терпимо. Держишь в голове, подгружаешь нужные файлы, работаешь. Два проекта сложнее. Одиннадцать невозможно без системы.

У каждого проекта свои роли, свои компетенции, свои сессии. Переключаешься между firmware для CAN-FD адаптера и криптодвижком на Python. Два разных мира. Разные API, разные паттерны, разные ограничения. Агент должен за секунды получить правильный контекст.

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

Три уровня контекста. Первый: что сделано, ключевые решения, текущий статус. Двести-триста токенов. Достаточно чтобы продолжить работу. Второй: детали, зависимости, открытые вопросы. Пятьсот-семьсот токенов. Для серьёзной работы. Третий: полный контекст, история решений, все связи. Для глубокого анализа или передачи другому.

RAG решает похожую задачу, но иначе. RAG нарезает документы на чанки и ищет по similarity. Это работает для вопрос-ответных систем. Для инженерной работы нужна структура: проект, сессия, роль, уровень контекста. Не “найди похожий кусок текста”, а “загрузи контекст этой сессии с этой ролью на этом уровне”.

Двенадцать правил из ошибок

Двенадцать правил. Каждое: шрам, не теория.

Агент удалил рабочий файл. Без предупреждения, без подтверждения. Просто взял и удалил. Я восстановил из git, но осадок остался. На следующий день добавил правило: “перед деструктивной операцией покажи что будет удалено и жди подтверждения”. С тех пор агент не удалял файлы без спроса.

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

Ещё через пару дней: переключил ветку в git, не сделав stash. Незакоммиченные изменения за два часа работы. Потерял.

В Agent Pipeline такие вещи решают guardrails на уровне инфраструктуры. Обёртки, middleware, валидаторы. Ещё слой кода поверх слоя кода.

Я решил иначе. Каждый случай зафиксировал как правило. Не в коде. В файле, который агент читает при старте сессии. “Перед деструктивной операцией покажи что будет удалено и жди подтверждения.” “После трёх неудачных попыток остановись и покажи что пробовал.” “Перед переключением ветки проверь git status и сделай stash.”

Так накопилось двенадцать правил. Каждое это шрам, не теория. Каждое появилось потому что без него агент делал глупость. С ними перестал.

Pipeline не учится на ошибках. Ты обновляешь middleware. Моя система учится: ошибка, правило, следующая сессия чище.

По сути, конвейер это признание: код будет с ошибками. Написал, отправил на review, получил правки, переписал, отправил снова. Двойная работа. Иногда тройная. Контракты решают иначе: precondition, postcondition, invariant. Ошибка не ловится после, а предотвращается до. Один цикл вместо трёх.

Лестница: от автодополнения до архитектурного партнёрства

Когда говорят “работаю с AI”, это может означать пять разных вещей.

• Level 0. Автодополнение. Copilot дописывает строку. Ты кодер, который быстрее печатает.

• Level 1. Вайб-кодинг. Вкладка с ChatGPT или DeepSeek. Скопировал, вставил, запустил. Работает, не трогай. Не работает? Скопировал ошибку обратно в чат. Самый массовый паттерн в 2026.

• Level 2. Генерация кода. “Напиши функцию X.” Ты кодер, который делегирует рутину. Cursor, Copilot Chat, Claude в IDE.

• Level 3. Задачи и workflow. “Вот задачи, давай.” Ты менеджер для агента.

• Level 4. Архитектурное партнёрство. Ты проектируешь систему. Описываешь контракты, роли, компетенции. Код это побочный продукт правильно организованного процесса.

Новый LAMP живёт на втором-третьем уровне. LangChain помогает оркестрировать генерацию кода и управлять задачами. Это полезно. Но потолок виден.

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

“Давно не пишу код” при таком количестве проектов и PKI-релизе. Это не лень. Это Level 4. Изнутри кажется “ничего особенного”. Даннинг-Крюгер наоборот: когда метод работает, перестаёшь замечать что он работает. “То что легко для меня, легко для всех.” Нет. Это не легко для всех. Тот же путь, который прошла индустрия от ассемблера к C, от C к Python. Каждый раз поднимаешься выше, предыдущий уровень становится деталью реализации.

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

Естественная реакция на любую работающую систему: скопировать структуру. Увидел что у кого-то есть роли, сессии, контракты, значит надо собрать такое же. Берут LangChain, создают “роль: coder”, “роль: reviewer”, вешают промты. Не работает. Или скачивают готовые skills из маркетплейса, подключают, запускают по расписанию. Получается чёрный ящик из чужих скриптов без общего контекста. Я называю это GPT Cron: человек видит что AI умеет делать задачи, логичный вывод автоматизировать. Скачал skills, повесил на расписание, запустил. Каждый skill написан разным автором, для разного контекста, с разными допущениями. Вместе они не работают как система. Работают как набор cron-скриптов с GPT внутри. Сложность переехала в инфраструктуру, контроль потерян.

Для управления двенадцатью проектами обычно нужны Jira, Notion, Slack, IDE, CI/CD, RAG, векторная база, оркестратор. Тут: папка с .md файлами и git. Сессии вместо Jira-тикетов. Контексты вместо Notion-страниц. Маршрутизация вместо RAG. Контракты вместо middleware. Звучит как упрощение. На практике это операционная система для разработки, которая выросла из задач, а не из архитектурного комитета.

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

Мои роли выросли из реальных задач. Десятки сессий firmware для CAN-FD адаптера, и из них кристаллизовалась компетенция: какие HAL-функции использовать, как обрабатывать DLC, какие ошибки типичны. Это не скачанный файл из маркетплейса.Это файл, который вырос из документации, форумов и реальных граблей. Механизм можно скопировать. Содержание нет.

Ключевое различие. Копирование: берёшь форму, надеешься что содержание появится. Строительство: содержание накапливается, форма вырастает из практики. Система не была спроектирована как “платформа”. Терял контекст, сделал сессии. Путался в проектах, сделал маршрутизацию. Агент повторял ошибки, сделал правила.

Фирмы проектируют “платформу с ролями” не имея проблемы которую решают. Копируют решение не понимая вопроса. Ровно как в 2006 ставили LAMP не задумываясь, нужен ли им вообще Apache.

Почему тебя не заменят

Разработчики боятся. “AI заменит меня.” “Джун с Copilot заменит сеньора.” “Компания купит Devin и уволит команду.”

Страх понятен. Но посмотрите кого именно заменят.

Google, Meta, Amazon уже включили использование AI в performance review. 80% разработчиков используют AI-агентов в 2026. Компании не спрашивают “хочешь ли ты работать с AI”. Они спрашивают “почему ты ещё не”. Но при этом доверие к точности AI упало с 40% до 29% за год. Все используют, мало кто доволен результатом. Потому что вопрос не в том, используешь ли ты AI. Вопрос на каком уровне.

В Agent Pipeline знания живут в промтах компании. Промты пишет тимлид, или нанятый prompt engineer, или отдельный AI-отдел. Разработчик заменяем. Уволили одного, посадили другого, промты те же. Компания владеет процессом, человек расходный материал. На бумаге. На практике компании тонут в сотнях промтов, которые ломаются при смене модели и дают разные результаты у разных людей.

Теперь другой сценарий. Инженер выстроил систему: сессии, роли, компетенции, контракты. Сотни сессий решений. Двенадцать коммитов в день на PKI-проекте. Это норма для команды из трёх-пяти человек. Здесь один. Другой человек может прочитать файлы. Понять структуру. Но выйти на тот же темп без своего опыта нет. Потому что компетенции выросли из практики конкретного человека. Правила родились из его ошибок. Контекст сессий отражает его решения.

Это как передать кому-то инженерный журнал за год. Прочитать можно. Продолжить можно. Но набрать тот же темп без своих записей в этом журнале -нет

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

Выбор простой: быть оператором чужого pipeline или архитектором своей системы. Компания может попробовать скопировать структуру. Может даже встроить сессии и роли в свой pipeline. Но кто будет наполнять эти сессии содержанием? Кто сформирует компетенции из практики? Кто напишет правила из своих ошибок? Инженер. Тех-лид не может написать компетенции за десять разработчиков. Компетенции рождаются из практики: десятки сессий с CAN-FD, грабли с DLC, правило из потерянного stash. Делегировать рефлексию нельзя. Чем больше инженер вкладывает в систему, тем незаменимее становится. Pipeline без его сессий это пустая оболочка. Это и есть щит.

Что нужно компании на самом деле

Компании покупают автономных агентов. Devin, Codex, Copilot Workspace. Платят за то, чтобы агент работал без человека. На практике: агент без контекста проекта ревьюит по общим правилам, не зная почему в этом модуле мы не используем ORM. Открывает PR, не понимая что ветка заморожена до релиза.

Конвейер и экзоскелет не конкурируют. Конвейер для рутины: автоматизировать code review на пятидесяти репозиториях. Экзоскелет для сложной работы: firmware, криптография, PKI, где нужен контекст и экспертиза. Они сосуществуют. При этом экзоскелет делает тот же code review качественнее, потому что проверяет не “есть ли тесты”, а “правильно ли обработан DLC в CAN-FD пакете”.

Devin от двадцати долларов в месяц, Teams пятьсот. Copilot Enterprise тридцать девять на человека. RAG-инфраструктура с Pinecone и LangSmith ещё столько же. Моя система: подписка на модель и папка с файлами. Стоимость инфраструктуры: ноль. Стоимость AI на весь PKI-проект: около тридцати долларов. Пятьдесят шесть сессий, оценка по тем где велась метрика. Токены это расходник. Как электричество: платишь по счётчику, не думаешь. Индустрия движется к токеновой разработке, как когда-то к облакам и CI/CD. Разница в том, что Devin продаёт подписку, а тебе нужен только API и метод.

Они это уже придумали

“Человек ставит цели. Компьютер считает.” — Ликлайдер, 1960
“Precondition. Postcondition. Invariant.” — Мейер, 1988
“Один инструмент. Один контекст. Не выходишь.” — Столлман, 1976

В 1960 году Дж. Ликлайдер написал статью “Man-Computer Symbiosis”. Главная мысль: компьютер не заменяет человека. Человек и компьютер работают вместе, каждый делает то, что умеет лучше. Человек ставит цели, оценивает результат, принимает решения. Компьютер считает, ищет, обрабатывает. Шестьдесят шесть лет назад. Сейчас это читается как описание того, что я делаю каждый день.

В 1988 Бертран Мейер опубликовал “Object-Oriented Software Construction” и формализовал Design by Contract. Precondition, postcondition, invariant. Индустрия посмеялась: слишком формально, двойная работа, Eiffel не взлетел. Мейер выковал меч. Ручная работа убила его. AI дал вторую руку.

Ричард Столлман строил Emacs как операционную систему внутри редактора. Почта, календарь, файловый менеджер, компилятор. Все смеялись: зачем всё в одном? Идея была простая: один инструмент, один контекст, не выходишь. Когнитивная нагрузка минимальна. Я работаю в одном окне с одним агентом на одиннадцати проектах. Переключение: “открой проект X”. Столлман вряд ли представлял AI-агента вместо Lisp-скриптов. Но принцип его: один инструмент, один контекст, не выходишь. Вместо .emacs, сессии и роли.

Три человека. Три идеи, которые считались устаревшими или смешными. Симбиоз человека и машины. Формальные контракты. Единый контекст. Всё это работает. Инструменты наконец доросли.

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

Вместо итога

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

Agent Pipeline это хороший стек. Для простых задач. Для сложных нужно думать про организацию знания. Сессии, роли, компетенции, контексты, рефлексия. Скучные слова. Работают.

Четыре месяца. Больше четырёхсот сессий. Одиннадцать проектов. Сто тридцать один коммит за одиннадцать дней, около тридцати долларов на AI за весь PKI-проект. Папка с файлами и git.

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

Не ждите готового pipeline. Начните с малого. Попросите агента в текущем чате вспомнить что вы решили по задаче на прошлой неделе. Какое решение, почему, что осталось.

Если не смог — теперь знаете с чего начать.

---

Источники

• Gartner: мультиагентные системы +1445% — chanl.ai

• 80% разработчиков используют AI, доверие упало до 29% — bunnyshell.com

• Google, Meta, Amazon: AI в performance review — hrexecutive.com

• Coursera: Applied Agentic AI Pipelines — coursera.org

• Austin Henley: Copilot Workspace UX — austinhenley.com

• GitHub Community: блокировка Copilot issues/PR — theregister.com

• awesome-cursorrules — github.com

• “Stop Engineering Prompts, Start Engineering Context” — medium.com

• J.C.R. Licklider, “Man-Computer Symbiosis”, 1960 — csail.mit.edu

• Bertrand Meyer, “Object-Oriented Software Construction”, 1988

• Первая статья: Design by Contract в эпоху AI — habr.com

• PKI-on-box — github.com/vasilievsv/hw.pki-on-box