Открытие дня. Все же знают dependabot, который обновляет зависимости всего и вся на гитхабе? Причем речь не только про пакетные менеджеры всех языков, но и например github actions и даже версии образов в Dockerfile. Так вот есть такое же решение, не привязанное к вендору. Небольшая предыстория. Помимо гитхаба у нас есть свой гитлаб с большим количеством реп, в котором так же находится инфраструктура запуска практик Хекслета. В нее входит репа с кучей Dockerfile под разные экосистемы, которые мы используем как базовые образы для практик запускающихся в браузере. В этой репе есть просто все что только можно себе представить: версии образов, версии дев тулов, версии зависимостей, причем часто указываемые напрямую в Dockerfile. Обновлять все это добро раньше было отдельным приключением. С иишкой стало проще, но один фиг это процедура, которой надо заниматься. А на днях делая очередное обновление, я подумал какого хрена, по-любому должно же что-то быть. Попросил клод найти и он нашел. Оказалось что есть такая штука как Rennovate, которая очень похожа на dependabot, но работает еще круче. Мало того, что она может обновлять все версии в стандартных случаях, так эта фигня умеет обновлять версии, которые заданы числами в разных местах за счет спец разметки:

# renovate: datasource=maven packageName=org.apache.maven:maven
ARG MAVEN_VERSION=4.0.0-rc-6
# renovate: datasource=java-version packageName=java-jdk
ARG JAVA_VERSION=25

Все это расставил сам клод и написал мне такую таску:

make deps-check 
images/base/Dockerfile            setuptools       83.0.0  -> 84.0.0
images/java-base/Dockerfile       java-jdk       25      -> 25.0.4+7.0.LTS
images/multi-language/Dockerfile  java-jdk   25      -> 25.0.4+7.0.LTS

Ну и все это добро отлично подключается к ci и шлет пулреквесты с обновками. Пользуйтесь

Перезапустили приложение, а все его файлы исчезли. В Kubernetes такое случается часто. Контейнеры могут удаляться и запускаться заново, а всё, что хранилось только внутри них, пропадает. Чтобы этого не происходило, приложениям подключают отдельные диски. Kubernetes сам находит или создает подходящее хранилище, подключает его к приложению и следит, чтобы данные остались на месте даже после перезапуска. Автор объясняет эту систему на простом тестовом кластере. Показывает, откуда берется диск, как Kubernetes его подключает, где искать ошибки и что проверять, если хранилище вдруг не заработало. Это небольшой гайд для начинающего сисадмина.

Почему Docker не всегда лучший выбор и чем его заменить Один бэкенд, одна база и nginx на дешёвом VDS с парой гигабайт памяти. Заворачиваешь всё в Docker по привычке, а дальше следишь за образами и логами, чистишь диск от старых слоёв, лезешь в цепочку DOCKER-USER, чтобы фаервол вёл себя предсказуемо, и на скудной памяти повышаешь риск словить OOM killer. К обычному Linux ты просто добавил вторую систему управления, которую надо понимать не хуже первой. И вот тут выясняется, что контейнеры-то были не обязательны. Для одиночного сервера набирается целый ряд замен под разные задачи, а на одном из вариантов автор прямо роняет мысль, что иногда лучший контейнер тот, которого нет вовсе.

⚡️ Снизили стоимость AI-оркестрации на -92.5% при росте точности до 97.8%: Разбор Архитектуры Monosnap SOTA v3.3 Пока большинство промптит единичные модели, мы перевели нашу мультиагентную систему на 4-уровневый Гибридный Спекулятивный Роутинг (Tier 0–3) + 5-слойную защиту контекста. 🛠 Как устроена система под капотом: 1️⃣ Черновой слой (Tier 0 SLM): Amazon Nova Micro ($0.035/1M) за 100мс делает триаж и черновой patch. 2️⃣ Кодирующий слой (Tier 1): Claude 3.7 Sonnet на AWS Bedrock. За счет выравнивания промптов по границам 4096t получаем 90% скидку на чтение кэша ($0.30/1M). 3️⃣ Совет Судей (Model Council): OpenAI GPT 5.6 (логика) + Google Gemini 3 Pro (визуальный UI) верифицируют черновик с конформным порогом (>= 0.70). 4️⃣ Защита Контекста: Вынос логов в SQLite FTS5 (SearchOS Lake) + офф-тред субагенты удерживают активное окно контекста на уровне 6–11% (18K-22K токенов) даже после 500+ шагов! 📊 Метрики бэктестов (N=500 прогонов): — Стоимость 500 задач: $0.0185 USD (vs $0.2475 baseline, -92.53% экономии) — Качество кодинга (Pass@1): 97.8% (vs 81.6% baseline, +16.1 п.п.) — Латентность: 2.12s (vs 6.84s baseline, -68.9% ускорения) — Статистическая значимость: Z = 95.70σ 🖼 В аттаче — подробные схемы архитектуры общего оркестратора, кэширующего прунера и би-темпоральной памяти CoALA. #AI Architecture #Agents #LLM #DevOps #SOTA2026

Вышел TypeScript 7.0 стал быстрее в 10 раз. что сделали: - Переписали компилятор на Go → нативная скорость + многопоточность - Ускорение сборки: x7.7 – x11.9 на реальных проектах - VS Code (repo): 125.7s → 10.6s - Sentry: 139.8s → 15.7s - Playwright: 12.8s → 1.47s - Память: -6% до -26% - First error в редакторе: 17.5s → 1.3s (x13 быстрее) Реальные кейсы: - Slack: -40% времени merge, CI check 7.5 мин → 1.25 мин - Microsoft: -400 часов в месяц на сборку билдов - Canva: ошибки в редакторе 58s → 4.8s Вопрос: сколько стоит 1 минута ожидания в вашей команде? Это классический эффект второго порядка. Вы ускоряете не билд. Вы ускоряете итерацию гипотез. - Было: 5–10 циклов в день - Стало: 30–50 циклов А значит: - быстрее проверка фичей - меньше batch-thinking - выше скорость обучения команды Это уже не DevEx. Это growth-фактор продукта.

Сайты падают по расписанию рабочей недели, а в выходные почти нет В четверг сайты падают на треть чаще, чем в воскресенье. Серверам к концу недели не тяжелее, просто в выходные никто не деплоит и не трогает прод. Сайты ломают люди, а не энтропия. Та же логика в графике по часам: главный пик приходится на рабочий день, но пятый по аварийности час суток это полночь, когда стартуют кроны и ночные выкатки в духе «всё равно никто не смотрит». За год мониторинга 6 500 сайтов набежало 108 312 инцидентов, и картина выходит скучнее любых страшилок про взломы и DDoS. Половина всех падений это простой таймаут, когда сервер жив, но задумался. А самое обидное ждёт ночью. Короткие сбои чинит автоматика, которой всё равно, который час, но если она не справилась, длинные инциденты в темноте закрывают на 35% дольше, потому что дальше всё зависит от человека, а человек спит. Выясним, сколько сайтов на деле держат обещанные три девятки аптайма и что за аномалия случилась в июне.

Pico Claw. Настройка за 15 минут Примерно с мая этого года использую Pico Claw для агентских сценариев. Меня спрашивали что это и как его настроить — записал на эту тему ролик. PicoClaw — AI-агент, который ест <10 МБ RAM и работает на любом железе. Я сам лично его использую для проверки разных гипотез применения ИИ-агентов в моих задачах. Ничем не хуже опенкло и гермеса для моих задач, но весит в десятки-сотни раз меньше. В ролике — полная установка на пустой VPS: безопасность (SSH, fail2ban), установка одной командой, подключение к ИИ-мозгам (без VPN), веб-интерфейс, Telegram-бот и ограничение доступа по IP. Ссылки на ролик на всех площадках: 📹 YouTube | VK | Rutube | Dzen 📹

Как говорит один мой хороший товарищ, за последние дни много чего "наклодил" и все-таки тариф Max не зря выбрал для своих задач. 1. Меня подвел хостинг VPS и почти два дня не давал студентам нормально учиться на курсе, так как все песочницы, помощники и прочие ништяки были заблокированы. Поэтому было принято решение переехать на Railway, так как уже надоело поддерживать самостоятельно работу VPS. хотя меня это сильно прокачало. На арену вступил Claude и за полдня перенес все, а это скажу вам "хлопотное дельце". И какой же кайф после Gemini, где надо делать 10-20-30 итераций, потом руками все переносить, беситься от ошибок, теперь работать с ИИ-агентами, которые все делают за тебя в рамках нескольких больших сессии. По итогу все перенесено и студенты довольны. 2. Вчера собрал себе тулу для генерации каруселей в LinkedIn и Instagram. С разными темами, типами слайдов, возможностью ИИ-генерации, редактированием, версионированием и другими полезными фишками. Магия какая-то. 3. Сегодня продолжаю работу над созданием инструмента для отложенного постинга с одной страницы, так как я хочу, когда хочу и где хочу. Ибо текущие решения бесят в своей разрозненности и ценовой политике. В общем, игрушка, которая затягивает... А что вы с помощью Claude или других агентов автоматизировали из своей рутины?

North-Mini-Code-1.0-w4a16 Квантованная версия (4-бит вес, 16-бит активации) первой модели Cohere для разработчиков: управление подзадачами, анализ архитектуры, code review. * Архитектура: Sparse MoE на базе Transformer. 30B параметров всего, 3И активно. Высокая скорость, низкие требования к GPU. * Контекстное окно: 256K токенов для анализа репозиториев целиком. * Максимальный вывод: до 64K токенов. * Поддержка: нативные инструменты, чередующееся рассуждение (interleaved reasoning) через JSON-схему. * Обучение: платформы SWE-Agent, mini-SWE-agent, OpenCode, Terminus 2 для устойчивости в реальных средах. Сценарии использования: * генерация кода и тестов * рефакторинг legacy-кода * автоматизированный code review в CI/CD * локальный AI-ассистент для приватности * создание агентных пайплайнов для аудита безопасности и unit-тестов #MoE #reasoning #coding

Ваш сайт не открывается из РФ? Привет привет❤️! Сорри что пропал - последние 2 месяца супер жестко кранчу рекрутерскую часть hirify.me, было не до постов. Но завтра (30) у меня день рождения, а сегодня я выпил пива, так что расскажу как я боролся с РКН. (пока писал пост, ДР уже наступил в моей таймзоне, так что с днём рождения меня и hirify! Его первый публичный релиз случился ровно год назад!🎉) Примерно в конце марта мне начали жаловаться, что ХФ как то нестабильно открывается из РФ. Хостился он на Timeweb в Нидерландах. А у них мало того что своего идиотизма хватает (то DDOS, то DNS отваливается, то сервак зависает), так ещё и РКН начал душить интернет. Параллельно с этим, ХФ вырос настолько, что 8/16 сервак за 70$ физически не справлялся держать нагрузку в момент когда оркестратор запускал очереди на парсинг (дело скорее в том что там дикая каннибализация CPU) В общем ждать было нельзя и я начал выбирать куда переезжать. У меня уже давно часть некритической инфры была на Hetzner, поэтому я знал, какие у них крутые серваки и низкие цены. Выбор оказался очевиден - я взял мощнейший Dedicated сервак с 20 CPU и 64 RAM всего за 54$. Полностью свой сервак без соседей, за меньшие деньги чем убогий Shared в таймвебе 🤯 Вместе с этим, я уже знал что Hetzner полностью заблочен в РФ, и нужна было, чтобы хостилось всё там, но при этом работало из РФ (30-40% трафика у меня оттуда). Было непросто, но через кучу экспериментов я нашел отлично работающую схему! ——— Глобально, идея крайне простая. Нужно сделать так, чтобы РФ юзер видел хостинг в РФ, а все остальные - нормальный основной хостинг. 1. Основной элемент схемы - GeoDNS провайдер. Это обычный DNS хостинг, который умеет в геороутинг. Например AWS, BunnyDNS, Gcore, ClouDNS (мусор + говно, даже не смотрите) и мб кто то ещё. Cloudflare к сожалению так не умеет, а ещё он заблочен в РФ. (В комментах пришли ребята с https://taucloud.ru, если бы я знал про них тогда, пошел бы не думая. Это буквально то что нужно в 1 клик!) Я выбрал Bunny за самую приятную админку и адекватные цены (это стоит 0$-10$). На выбранный хостинг переносятся DNS записи. Потом создается DNS скрипт по примеру из доки и подключается как особый тип DNS записи. (пока не выполнен шаг 2, лучше отдавать один и тот же IP) На случай если придёт идея спрятаться за CDN, вместо этой схемы - я пробовал, это не работает надёжно. Cloudflare заблочен полностью, у Bunny работает 50/50, в зависимости от того, какую ноду выдаст юзеру, рандом короче. 2. Вторая важная часть - прокси сервак. Берете в РФ у любого хостера базовую VPS за минимальные деньги, ставите SSH ключ, чтобы из локального терминала был доступ и кидаете промпт из комментариев в своего ИИ агента. На этом же шаге можно попросить поднять .ru алиас который будет так же проксировать на основной сервак. 3. Прописываете айпишник, который отдал агент в Geo-скрипте. 4. Защита от РКН ботов - бонусный пункт! Если вы хотите увеличить шансы, что РКН вас не заметит, попросите агента интегрировать в оба сервера вот этот репозиторий - https://github.com/freemedia-tech/nginx-rugov-block. Несмотря на давние коммиты, блеклисты апдейтятся. Всё, вы великолепны 🎉, а ваш сайт доступен из РФ и при этом для всего мира вы не выглядите как РФный сайт!

От подписчика: Отчет Faros.ai про реальные цифры продуктивности разработки с ИИ. Ну... Не все так однозначно... Это реальные метрики кода от требований до доставки. Выборка – 4000 команд за 2 года, сравнение внутри одних и тех же компаний между кварталом минимального и максимального использования AI. Главные цифры: – Продуктивность отдельного разработчика выросла, но скромно, судя по merge requests. Примерно +16 процентов, а не 10x – При этом скорость доставки релизов упала на 11 процентов. Это системная метрика, она про доставку ценности клиенту – Поток замедлился на каждом шаге. Фича проходит каждый этап на 80–480 процентов дольше – Качество просело резко: дефекты вверх, переоткрытые тикеты вверх, code churn (доля переписанного кода) – аномальные 861 процент Узкое место сместилось в ревью. Стадии Ready for Review и In Review раздулись, а ревью стали пропускать на 31 процент чаще – классическое поведение людей на бутылочном горлышке. Сам Faros пишет прямо: организации генерируют больше кода, чем система способна отревьюить и смержить. Автор гоняет данные через закон Литтла (L = λW). Если лид-тайм и WIP растут быстрее, чем заявленная продуктивность – значит скорость потока на самом деле падает. По его расчётам реальная пропускная способность просела на 8–70 процентов в зависимости от допущений. То есть «продуктивность индивидуального разработчика» и «поток готовых фич» поехали в разные стороны, а платят клиенты именно за второе. Тойота в своё время победила американский автопром фанатичным фокусом на качестве и принципе «не передавай дефект на следующую станцию». Чем позже находишь баг, тем дороже он стоит системе. LLM делают ровно наоборот: впрыскивают больше дефектов на входе и переносят их отлов в ревью, где ловить дороже и хуже. Любопытная деталь: гипотеза «AI усиливает сильных» не подтвердилась. High-performing команды деградируют так же, как все остальные. Тут есть с чем спорить по методологии – это наблюдательное исследование, не причинно-следственное, и автор сам это признаёт. Но направление мне кажется честным и совпадает с тем, что многие из нас чувствуют на практике: индивидуальная скорость растёт, а на уровне организации профита не видно. Главная мысль, productivity не равно value. Локальный разгон одного этапа не двигает систему, если узкое место в другом месте. Если внедряешь AI в команду и не перестраиваешь ревью и QA под возросший объём генерации – ты просто переносишь бутылочное горлышко вниз по потоку и копишь work in progress. И отдельно зацепил тезис про «сначала черновик от LLM, потом доработаю». Автор считает, что это задом наперёд: первый черновик – это и есть твой интеллектуальный вклад, момент, когда ты реально продумываешь структуру. LLM сильна как редактор и спарринг после, а не вместо мышления. С этим скорее согласен - чем больше вложений на первых этапах, тем лучше результат. Короче, уделяйте МАКСИМАЛЬНОЕ внимание требованиям, а не пытайтесь зафигачить 100 фич и отдать все тестировщикам. Источник: https://unessays.substack.com/p/talk-is-cheap

Раньше ПО работало шустро, потому что иначе было никак Пайплайн упал — подняли память. Сервис затупил — добавили ядер. Дежурный заложил буфер, потому что никто не хочет подрываться ночью. Через полгода исходного контекста уже никто не помнит, и эта конфигурация становится строгим требованием. Парадокс в том, что сервис при этом выглядит здоровым. Он использует 10% от выделенных 64 ГБ, мониторинг светится зелёным, команда эксплуатации спокойна. Мы научились поднимать тревогу при перегрузке, но почти никогда не создаём алёрты на структурную пустоту. Разберёмся, где именно проходит граница между неизбежной сложностью и накопленным суеверием.

Чем CC на самом деле круче Codex с точки зрения бизнеса? В целом, будем честны, они уже плюс-минус одинаковые. Да, Claude лучше делает UI, а Codex педантичнее следует правилам. Обгоняют друг друга по разным фичам, но в основном в мелочах Но есть одна особенность, которая может быть критической при выборе Codex vs Claude Code для компании. По крайней мере, для тех компаний, где разрешен гитхаб Это automations (codex) vs routines (cc) Просто один из самых частых запросов у бизнеса сейчас: 1. Научите наших доменных экспертов автоматизировать себе задачки 2. А потом сделайте, чтобы часть задачек запускалась в фоне, чтобы не тратить на них фокус Раньше, переход из первого во второе означал кучу приседаний с SSH, CI/CD, Docker и кучей других слов, которые люди учить не хотели и правильно делали Теперь рутины в Claude Code это решают – там достаточно разобраться как запушить проект с AGENTS.md и скиллами на гитхаб (проверено, с этим справляются), скопировать .env, если был, и установить триггер по таймеру (но можно и вебхук, если хочется запускаться в ответ на внешнее событие) Всю сложность по деплою, триггерам, и т.д. забирает на себя антропик И для компаний, где мало разрабов или у них нет времени на создание такой инфраструктуры для своих нетехнических коллег – это прям киллер фича @ai_grably

Когда вы строите что-то помощнее лендинга, у вас появляется какая-то инфраструктура и сервисы. И обязательно настанет момент, когда оно упадёт. Поэтому нужно будет строить сигнализацию, систему алертинга, которая известит нужных людей об инциденте. Классическая связка в вебе - Prometheus+Grafana, но вот попался еще опенсорсный инструмент - Nightingale. Пишут, что в отличие от Grafana, делают упор именно на алертинг. Собирает данные из разных источников, знает Prometheus, ElasticSearch, Loki, ClickHouse, MySQL, Postgres. Но сами они рекомендуют Categraf. Есть настройка разных правил - алертингов, подписок, уведомлений. Есть конвейеры событий. Есть даже MCP-сервер, чтобы общаться с API по-человечески. Проект активно развивается, 161 контрибьютор #devops

Что такое DevSecOps и почему вокруг этой профессии столько шума Если максимально упростить, DevSecOps -это специалист, который внедряет безопасность прямо в процесс разработки программного обеспечения. —-Раньше всё работало так: программисты пишут код, тестировщики его проверяют, сисадмины выкатывают на сервер. И только в самый последний момент проект отдавали отделу безопасности. Безопасники находили кучу уязвимостей, возвращали всё назад, сроки срывались, все ругались. DevSecOps ломает эту схему. Его задача - сделать так, чтобы код проверялся на уязвимости автоматически, на каждом этапе написания, а не в самом конце. Чем конкретно занимается этот человек? * Настраивает автоматические сканеры. Как только разработчик сохраняет кусок кода, специальный софт сразу проверяет его на известные баги, "дыры" и слитые пароли. * Защищает инфраструктуру. Настраивает доступы к серверам и базам данных так, чтобы условный хакер не мог зайти туда одной левой. * Дружит разработку и безопасность. Он не просто говорит “так нельзя”, а настраивает инструменты (CI/CD пайплайны), которые помогают программистам писать защищенный код быстрее. Почему это сейчас в тренде и дорого стоит? 1. Экономия денег. Найти и исправить ошибку в безопасности, пока код еще пишется, в десятки раз дешевле, чем чинить приложение, которое уже взломали и обокрали в продакшене. 2. Дикий дефицит кадров. Обычных программистов много. Безопасников тоже хватает (на самом деле не хватает). А вот людей, которые одновременно понимают, как пишется код, как работают сервера (DevOps) и как устроены хакерские атаки (Sec) - единицы. По сути, это логическая эволюция DevOps-инженера. Если вы уже умеете настраивать сервера и автоматизировать деплой, добавление навыков безопасности (OWASP, аудит контейнеров, сканеры уязвимостей) автоматически переводит вас в ТОП по востребованности и зарплате.

#мнение Место менеджмента AI-native оргструктуре Привет, читатель! Не знаю заметил ли ты, но я избегаю 3 тем: SOTA-моделей, автономных агентов и AI native команд/компаний Наткнулся на доклад AWS про команды в мире агентского ИИ. Не про инструменты, а про то, как меняется операционная модель когда стоимость владения падает: 1. Экономика AWS дает развилку Use / Compose / Build. Build оправдан только при уникальном процессе. Для большинства первичен разбор потока: где ценность, где теряется контекст, где нужна проверка. AI-native начинается не с модели, а с описания процесса как системы исполнения 2. Таланты и новые роли AWS вводит expert generalist: человек, который ведет процесс целиком. Фаулер разделяет why-loop и how-loop: человек сильнее в выборе что и зачем, агент в исполнении. Эндрю Энж: сборка ускоряется, узкое место смещается в продуктовые решения Отсюда роли. Product builder вместо PRD приносит проверяемый прототип. Product Engineer сам ближе к пользователю и метрикам. Forward deployed engineer тащит агентов в процессы клиентов, потому что между демо и продакшеном лежит слой интеграций и ответственности 3. Структура команд Четыре формы: пирамида, ромб, перевернутая пирамида, песочные часы Пирамида растит людей, но буксует на передачах. Ромб появляется когда режут джунов: пайплайн кадров умирает. Перевернутая пирамида как боевая капсула: сильные спецы и агенты. Песочные часы: автономные команды сверху, тонкий управленческий слой, обучение снизу. Team Topologies дает тот же принцип: команды вокруг потока ценности и когнитивной нагрузки. AI-native команда это не сквад с агентами, а компактная единица с ответственностью от начала до конца 4. Операционная модель Модель A: разработка строит, эксплуатация поддерживает, для агентов не работает. B: построил сам, запускаешь сам, работает в малом масштабе. C: автономные команды плюс платформа. Продолжение DevOps, не новая история. Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps дороже 5. Управление и контекст Управление агентами сводится к идентичности, правам, допустимым действиям и аудиту. Не регламент на полке, а исполняемый контур ближе к PRR из SRE. Фаулер формулирует: агент это модель плюс обвязка из правил, инструментов, проверок и контекста. Документация часть среды исполнения. Палантир-модель показывает: доменные понятия должны быть явными 6. Проджект-функция Каган разделяет продуктовые и фича-команды. ИИ ускоряет фича-команды, но не делает их продуктовыми Старая админ-функция сжимается. Отчеты, статусы, пушинг, перфоманс ревью, это компенсация плохой структуры. Новая мидл менеджер-функция это управление условиями исполнения. AI-native убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь