Сказки из IT - Егор Урванов

А у меня день рождения! 😊 Я буду рад, если вы поставить лайк под этим постом 😁❤️ А ещё я люблю лайки, репосты и просмотры 😏

Итак, анонсы докладов митапа 11 июня ⏺HINT или почему "Я робот" - это пророчество ⏺layered spec - spec programming language ⏺Применение Harness Engeneering по методологии OpenAI в своих проектах по разработке 18 июня ⏺Основной буст от ИИ — рост личной продуктивности, остальное следствие ⏺Command Rails: рельсы для надёжной разработки с AI-агентами ⏺Как я вести разработку автономно ⏺Сравнение харнесов: Claude code, Hermes, open claw, open code —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Митап О чем? На следующей неделе в четверг будет митап по агентам, вайб-кодингу и всему, что прямо или косвенно связано с ИИ. Ограничений нет Цель митапа Найти паттерны, которые можно стабильно применять в бизнесе и прикладных задачах. Удачные находки те, которые у многих появляются неазвисимо Таких митапов будет серия #Митап 🕖 Время: Четверг 19:00 11.06.2026 📍 Место: онлайн, регистрация будет позже Анонс докладов будет позже

Занимаюсь тулой для спеков. Что-то вроде openspec, только заточено под то, чтобы агент сам читал стейт из файлов и не терял контракт между сессиями. А акцнет на чтение людей делаю меньший Отличие от ближайшего конкурент openspec в том, что я хочу, чтобы требования можно было бы давать ещё более верхнеуровневыми, чем в опенспеке, а клод бы сам находил противоречия. При этом хочу стабильности и снижения потеряшек требований, хотя, по-умолчанию считаю, что это chaos-driven-development, как k8s Пока сыро, баги есть. Но уже юзаю сам, постепенно объединяю со скиллами и правилами Кто потыкает — расскажите что сломалось ⚠️⚠️⚠️ В будущем релизе планирую сделать SRE-скилл, который умеет интеграцию с гитлабом и отправлять пулл-реквесты по инцидентам —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Тот момент, когда клоду стало впадлу переделывать работу —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Болтали тут про OpenSpec и SpecKit Мне не зашло: - У меня уже довно есть пайплайн — требования генерятся через gpt и падают в confluence/jira. Openspec туда никак не встраивается, нужно делать всё отдельно, и проще было просто ctrl+c ctrl+v из jira в контекст - Токены. Генерить спек на клоде дорого — упираешься в лимиты. Если генерить на gpt — непонятно зачем вообще тогда openspec - Проблема с контекстом. Пробовал хранить спек прямо в репе — раздувает контекст, но эффекта особо нет. Модель всё равно не читает его автоматически, нужно носом тыкать в конкретный файл. А если класть в rules — с третьего сообщения уже 200к токенов набегает, когда контекст нужно уже очищать - Ну и живая разработка плохо ложится на спек — постоянно какие-то промежуточные доработки, которые в спек не вписываются - spec-kit не пробовал, у него вроде есть jira-интеграция через расширения, может там получше. Но фундаментальная проблема с контекстом одинаковая у обоих —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Уже не первый раз слышу аналитику от BCG, PwC, Stanford и других ребят, что люди стали сильнее выгорать с использованием агентов Это только у меня такое начало появляться в последнее время от Claude? —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

LLM чинит прод быстрее тебя, просто ты задаёшь тупые вопросы Ты сидишь смотришь на баг, как баран на новые ворота, и пишешь в Claude: “не работает, помоги” — ну конечно он тебе ответит чем-то размытым, потому что ты сам не понял, что происходит; отладка через LLM — это не про «спросить», это про то, чтобы сначала самому собрать трассировку системы: кто дернул, куда пошло, какое состояние было до/после, где разрыв, иначе ты не инженер, а просто пассажир в чате Самый грязный хак: LLM не дебажит код — он дебажит твою модель в голове, и если у тебя там каша, он усиливает кашу; поэтому нормальный флоу такой: сначала ты руками раскладываешь цепочку событий, как в моём недавнем кейсе (User → Telegram → handler → FSM → LLM → DB), фиксируешь где ожидание одно, а реальность другая, и только потом кидаешь это в Claude — и он уже не "думает", он валидирует твою гипотезу или ломает её Sequence diagram: ты рисуешь поток, и внезапно видно, что у тебя не "кнопка сломалась", а состояние сменилось между двумя сообщениями, или контейнер вообще с другим кодом живёт, или LLM скорит raw вместо structured — текстом ты это не увидишь, мозг срежет углы, а диаграмма нет, она тебя же и ловит на вранье Последняя схема — это твой способ думать: ты показываешь Клоду не симптом (“сбросилось всё”), а расхождение в процессе (“должно было пройти A→B→C, а у меня A→C, B пропало”), и он сразу цепляется за конкретную точку, а не плавает в абстракциях… и да, в этот момент он становится не советчиком, а реально вторым инженером на инциденте LLM ускоряет дебаг в десятки раз не потому что он умный, а потому что заставляет тебя перестать быть тупым: либо ты формулируешь систему как последовательность состояний и переходов — либо продолжаешь тыкать "перезапусти контейнер" и удивляться, почему опять всё поехало… —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Кодишь как бог, а каждый раз объясняешь ИИ одно и то же? ну давай ещё раз, конечно… Сильная модель, да. Но как только открываешь новый проект — снова это: “пиши тесты сначала”, “не лезь в инфру”, “коммит нормально оформи”… и ты такой сидишь, повторяешь это как мантру, будто у тебя не код, а дрессировка попугая. Потом удивляешься, почему он всё равно пишет как стажёр… потому что ты его таким и оставил. Берёшь → клонишь .claude → и внезапно оно начинает жить по правилам, а не по настроению. Скиллы, агенты, конвенции — всё уже лежит, не надо изобретать “свой подход к TDD” в каждом репо заново. Он не становится гением, но перестаёт быть хаосом… и вот это уже неприятно удобно. Самое отстойное — обратно уже не хочется. Когда у тебя есть /tdd, который реально ведёт процесс, или /commit, который не позорит тебя перед историей git… внезапно начинаешь замечать, насколько раньше было криво. Типа жил нормально, а потом увидел, как можно без боли. Короче, это из серии “попробовал — и теперь смотришь на другие проекты с лёгким отвращением”. Ну и да… если вдруг захочется сохранить это ощущение где-то рядом, чтобы не потерять — ты знаешь, где кнопка 😉 —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Resilient AI Pattern. x70 к скорости релизов при фиксированной доле ошибок в 2-3% Последние разы это были не “умные слова про архитектуру”, а конкретные куски одной системы: fallback, strangler, anti-corruption… они по отдельности выглядят как паттерны, но вместе это уже другой способ делать разработку, где скорость перестаёт конфликтовать с качеством Смысл простой, но обычно его пропускают: ты больше не пытаешься сделать идеальный код до продакшена, ты строишь систему, в которой неидеальный код не может навредить — и вот тогда появляется возможность реально ускоряться, а не играть в ускорение Что происходит дальше генерация кода становится нормой → тесты дают минимальную валидацию → ACL не даёт протащить мусор в домен → fallback гарантирует завершение → strangler позволяет заменять куски без риска → канарейка показывает реальность, а не “кажется работает” И вот из этого внезапно собирается результат - x70 к time-to-market — не магия, а следствие - ошибки возвращаются к тем же 2–3% — потому что система их не накапливает, а отрезает

def handle(data): try: result = ai_call(data, timeout=0.2) # быстрый, но нестабильный путь safe = validate_and_map(result) # ACL: чистим и приводим к домену return safe except Exception: return fallback(data) # гарантированный baseline

Если читать каждый паттерн отдельно — кажется, что это про стабильность, если сложить их вместе — становится понятно, что это про скорость без потери качества —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Интеграция без Anti-Corruption Layer — это ... Ты думаешь, что просто “подключил сервис” или “импортнул либу”… а по факту ты притащил в свою систему чужие контракты, кривые модели, странные статусы и поведение, которое вообще не обязано совпадать с твоей логикой — и дальше сидишь такой “ну вроде работает”, пока однажды это не начинает ломать тебе доменную модель изнутри Самое мерзкое — оно не падает сразу, оно тихо протекает: поля начинают значить разное, статусы не совпадают, инварианты нарушаются, и у тебя уже не система, а гибрид Франкенштейна, где половина логики “ну потому что там так приходит”, и ты это даже не контролируешь Лечится это не “договоримся с API” (лол, конечно договоришься), а тупо — ставишь Anti-Corruption Layer и говоришь: всё, что снаружи, — это не наша реальность, мы это мапим, валидируем, режем, и только потом пускаем внутрь; не прошло проверку — до свидания, живём без этого Ты больше не зависишь от того, как там кто-то что-то поменял, у тебя есть своя модель, свои инварианты, и любой внешний вызов — это не “часть системы”, а подконтрольный перевод через границу, где ты решаешь, что правда, а что мусор Если этого слоя нет — поздравляю, у тебя нет архитектуры, у тебя есть shared failure domain, только не по latency как с фолбэком, а по смыслу данных… ... — это оно просто ещё не запахло —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Старую систему никто не выкидывает, её обматывают новой как лианой, пока та не сдохнет сама… да, звучит криво, но именно так Strangler и работает — не переписал, а перехватил поток и начал душить по кускам, пока старое просто не перестанет получать трафик, и это единственный способ не устроить себе массовый факап в проде, потому что “перепишем всё” — это всегда сказка для джунов, заканчивается одинаково плохо Да, тут важно, что Strangler — это не на 100% то, что описано на картинке, но очень близко. Суть детальнее загуглить можно —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Система без fallback — это просто отложенный инцидент Как обычно словили инцидент: любой новый вызов живёт в общем контексте и при проблеме не падает, а начинает тормозить всё вокруг — растёт задержка, копится очередь, система “жива”, но уже разваливается Исправляется это просто: каждый вызов изолируешь, задаёшь лимит по времени и правило — либо отработал, либо сразу переключение на fallback; без повторных попыток “а вдруг сейчас получится” (хотя ретраи нужны, сеть никто не отменял) После этого система перестаёт зависеть от поведения отдельных частей: не отработало → отрезали → пошли дальше; если этого нет — это период, пока ещё не вжарило —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Привет! Помогаю коллегам и друзьям с podlodka crew Я там и сам выступаю про AI и паттерны применения рассказываю А ещё можно промик получить на участие. Репосты приветствуются

Вспоминается старый анекдот Открываю туториал: «Соберём проект за 5 минут». Копирую код — не работает. Думаю: ну ок, я тупой. Проверяю — не работает. Гуглю — все пишут «работает». Уже начинаю сомневаться в реальности. Переворачиваю страницу, а там мелким шрифтом: «Если у вас не работает — поздравляем, вы действительно всё сделали правильно. Теперь начнётся настоящая разработка». Это только у меня клод решает поглядеть секреты? —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

LLM orchestration layer — новый инфраструктурный слой между интерфейсом, моделями и данными. В классическом бэкенде API ходит в сервисы и базы почти напрямую, но в LLM-системах такой подход быстро превращается в помойку: где-то промпты, где-то тулзы, где-то ретривал, где-то RBAC, где-то анти-инжекшн, и всё это размазано по коду как сопли по монитору. Поэтому на практике появляется отдельный orchestration layer, который управляет пайплайном intent → policy → tool selection → retrieval → response, контролирует доступ к инструментам, режет контекст, маршрутизирует запрос между моделями, логирует шаги агента, навешивает guardrails и держит инварианты безопасности. По сути это не “обвязка вокруг LLM”, а новый application runtime для agentic-систем: если его нет, у тебя не архитектура, а набор случайных вызовов модели с надеждой, что сегодня ничего не протечёт. —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Opus 4.7 released 🥳🥳🥳

Prompt injection — это не проблема промпта, а проблема архитектуры. Если LLM может напрямую читать чувствительные данные или вызывать действия (API, транзакции, админ-методы), то любой пользовательский текст становится по сути удалённым управлением системой. Пользователь пишет “ignore previous instructions” — и модель может начать использовать инструменты, которые ей не предназначались. Это эквивалентно RCE на уровне логики приложения, только вместо shell-команд выполняются API-вызовы. Единственный надёжный способ защиты — архитектурный: LLM не должен иметь прямого доступа к данным и действиям. Он должен работать через capability-ограниченные инструменты, а решения о доступе принимаются вне модели (policy engine / control plane). Тогда prompt injection превращается из критической уязвимости в обычную ошибку классификации. —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Теперь ты не внутри контекста. Ты над ним и это даёт возможность увидеть всё целиком Раньше разработчик жил как крыса в лабиринте: видел свой use case, свой сервис, максимум соседний. Bounded context был где-то сверху — на схемах, в головах «архитекторов», в доках которые никто не читает. Ты не был системой. Ты был её функцией. И честно — тебе было норм, потому что ответственность тоже была локальной. Контекст был выше тебя. Ты не понимал его ценности, потому что не видел систему целиком. Для тебя «границы» — это просто ограничения: нельзя импортнуть, нельзя дернуть, нельзя быстро сделать. Архитектура мешала, а не помогала. Ну и логично — ты внутри неё, как процесс внутри ОС, тебе не видно ядра. А теперь появляется агент. И внезапно он делает то, что раньше делал ты — только быстрее, тупее и без страха. И ты больше не исполнитель. Ты смотришь сверху, как он ходит по системе. И впервые видишь: где нет границ — там он течёт. Где есть ACL — там он стопорится. Где события — там он вынужден играть по правилам. И вот в этот момент щёлкает: bounded context — это не про код. Это про контроль поведения. Это sandbox для акторов, которым нельзя доверять. Раньше это были «другие команды». Теперь — это агенты. А ты больше не внутри. Ты тот, кто решает: куда можно ходить, а куда — нет. И если раньше ты ломал систему случайно, то теперь ты смотришь, как её ломают системно. И либо ты ставишь границы… либо у тебя не архитектура, а кормовая база —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура

Bounded Contextы были «архитектурным онанизмом»… пока не пришли агенты и не начали ломать прод Раньше на bounded contextы смотрели как на странную игру взрослых людей в DDD: рисуют квадратики, придумывают “единый язык”, городят ACL — а фича как ехала 3 недели, так и едет… и вроде можно было проще: один сервис, одна база, импортнул модель — поехали, зачем этот цирк с “контекстами”, если всё и так работает (ну почти). Проблема в том, что “работает” — это пока система маленькая и люди ещё держат всё в голове… а потом начинается классика: один сервис знает слишком много, второй случайно зависит от третьего, данные текут как хотят, и любое изменение — это лотерея: починил одно, сломал три, но тесты зелёные, значит норм, да? да?.. Bounded contextы тогда казались оверхедом, потому что их ценность не видна сразу — ты платишь за границы, за изоляцию, за перевод типов… но не получаешь “быстрее релиз” в моменте, наоборот — медленнее, больнее, больше кода, больше “зачем это всё”. И поэтому большинство делали как обычно: склеивали домены, шарили модели, тянули зависимости напрямую… пока система не превращалась в липкий ком, где любое движение — с риском оторвать себе руку, но зато без “архитектурного онанизма”, всё по-пацански. А потом… появились агенты. —————— Менеджер? Давай сюда! Ищи работу здесь Технологии и архитектура