Book-as-context: архитектура по Таненбауму
Просишь «интеграцию с ERP» — получаешь FTP-обмен. У модели нет предметной базы. Даю агенту предметную базу — Таненбаум через wiki-подложку.
Григорий Добряков
Howto-серия
Инженерные разборы
Формат: задача из практики → как к ней подошёл → репозиторий или видео → обозначение рисков и границ применимости. Разборы, которые можно изучить, перенести в ваш контур и адаптировать под свои задачи.
В каждом howto явно обозначаю зону применимости: где решение слабеет, при каких условиях его нельзя тиражировать, что может пойти не так. Конкретные сценарии отказа и принятые trade-off'ы.
Просишь «интеграцию с ERP» — получаешь FTP-обмен. У модели нет предметной базы. Даю агенту предметную базу — Таненбаум через wiki-подложку.
Межорганизационное согласование контракта агентами: два бота из разных компаний сами вырабатывают OpenAPI-спеку, люди в обсуждении не участвуют.
Vector-only теряет термины, которых нет в embedding. Retrieval с тремя режимами под book-as-context: у каждого чанка виден источник, агент может сказать, зачем взял именно его.
Наивный MCP-сервер блокируется на долгих операциях. Async job queue: submit → poll, и 404-after-completion как сознательный stateless-trade-off.
Агент ищет готовый workflow; при отсутствии сам собирает граф и импортирует в n8n. При следующих запросах — переиспользует. Детерминированный результат.
Собран на корпоративной тренировке — ответ скептикам «вайб-кодинг не для серьёзных систем». MLOps-стек с feature store и observability. На разборе — результат, риски и границы применимости.
Как держать планку при массовом AI-кодинге: конвенции в toolchain, с которым работают каждый день — версионируемые Cursor rules в репозитории.
«Сделай event-tracker» без уточнений. Два репо: UDP fire-and-forget и HTTP+PostgreSQL. Durability решается при выборе между ними.
«Отправил в Kafka и забыл» — работает до первого сбоя. Это распределённый коммит с фазами, а dual write без outbox — отложенный инцидент.
Eval зелёный, прод красный — часто потому что тестировали на тех же данных, что на демо. Release gate из трёх слоёв: regression по инцидентам, distribution diff к снапшоту, spot-check людьми до деплоя.
Задача не идёт в разработку, пока в Jira нет цели, scope и AC. Project context L1/L2/L3, human approve, воспроизводимый артефакт jira-clarify-bot.
Specify → clarify → plan → tasks → implement. Spec Kit на мультисервисной иллюстрации: в фокусе — чёткая работа с артефактами, независимо от предметной области.
Firewall контролирует сеть, но не семантику payload. Локальная модель детектирует персональные данные и секреты до того, как текст уходит за периметр организации — исполняемый фильтр вместо policy и code review.
Реализация стандарта Google A2A через общий git-репозиторий: люди и агенты разных компаний ставят задачи друг другу без HTTP-сервера. Атомарный захват, Iteration Policy, полный audit trail из коробки.
Пишешь /onboard fb-post-writer — скилл прогоняет новый скилл через 8 шагов:
шесть детекторов конфликтов, sandbox interview и карточка в реестр. Конфликт
найден до мерджа, а не неделю спустя.
Git как канал наблюдаемости, разделение постановки и исполнения через
inputs/ →
outputs/,
least privilege через файловую структуру. Три слоя — без PAM-контура и
отдельного SIEM.
Гибрид детерминированных метрик (bash + awk) и LLM-интерпретации поверх. Каждое
утверждение в отчёте ссылается на SHA или число — никаких выдуманных паттернов.
Proof: реальный прогон на
.claude/skills/
этого репо с конкретными архитектурными выводами.
Архитектурные разборы, AI-assisted разработка с governance, практики так, чтобы результат держался на процессе, а не на одном удачном промпте и героизме в review.
Написать на почтуФормат серии