Как говорит один мой хороший товарищ, за последние дни много чего "наклодил" и все-таки тариф 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 убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь