Программирование *

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

В статье разбираем, как data contracts помогают фиксировать структуру, правила и ответственность за данные — и почему это спасает витрины, отчёты и нервы дата-инженеров.

Прошлая статья была обзорной — что такое redb.Route, зачем нам понадобился свой Apache Camel под .NET, как выглядит боевой маршрут. Если не читали, коротко: это fluent C# DSL для интеграции — 22 коннектора (~30 URI-схем, если считать https/wss/es-варианты), ~30 паттернов EIP нативно через 41 процессор, 8 in-process компонентов, компилируемый expression-движок. Сегодня заходим внутрь. Не список фич, а рабочий разбор.

Серия будет длинной, поэтому сразу скажу, что и в каком порядке:

На днях я заметил, что квота Ollama Cloud Pro тратится быстрее обычного. Значительно быстрее. За семь дней я сжёг 603 миллиона токенов и не понимал, куда они уходили.

Я открыл логи Hermes Agent и нашёл то, о чём не знал: блок auxiliary: с двенадцатью фоновыми задачами. Сжатие контекста, извлечение из веба, vision, поиск по сессиям, подбор навыков — всё это молча запускалось при каждом моём сообщении. Каждая задача стояла на provider: auto. И поскольку у меня не было ключей для цепочки fallback, каждая молча откатывалась на kimi-k2.6, мою основную модель на триллион параметров.

Я понятия не имел, что это происходит. Пока я печатал одно сообщение, агент отправлял одиннадцать других в фоне — через ту же модель, из того же квоты, не показывая мне промпты. Только сжатие контекста срабатывало 10–20 раз за длинную сессию, каждый раз отправляя всю историю.

Всем привет!

 Это мой первый пост на Хабре и я хотел бы представиться. Меня зовут Алексей, я работаю в ИТ компании, но моя работа совсем с ИТ не связана — я комплаенс офицер (человек который следит, чтобы компания соблюдала свои же собственные правила). Пару месяцев назад решил сделать для души Телеграм бот, просто чтобы чуть лучше понимать процессы разработки и работу разработчиков.

Я достаточно активнопользуюсь Телеграм и подписан на кучу каналов, большинство из них уже давно на вечном мьюте — читать большое количество каналов просто нет времени, хотя там наверняка есть что‑то полезное или интересное для меня.

В итоге появилась идея, которую на мой взгляд @durov должен был реализовать уже давно — создать бот, который читал бы интересные для меня каналы и формировал персональную ленту из постов, актуальных для меня.

Ниже небольшой отчет о проделанной работе и рассказ о функционале, буду очень рад обратной связи.

Всем привет, на связи команда ZeBrains. Этот текст про то, как мы перестали просто использовать ИИ и начали с ним работать по-настоящему. Про настоящие проекты, шишки и один файл, который изменил всё.

Спойлер: один разработчик теперь закрывает полный цикл от ТЗ до прода. Без дизайнера, без аналитика, без DevOps. За месяц. Но путь к этому был не таким прямым, как кажется.

У инженера на промышленном объекте две машины: Контур 1 с интернетом и LLM, Контур 2 — физически изолированный, для реального кода. Между ними асимметричный мост: запрос наверх — через фильтр и бумагу, код вниз — через Gate с подписью и SHA-256, без real-time API. Главное: air-gap — это не «нет провода», а четыре проверяемых условия, и почти каждый громкий инцидент (Stuxnet, Triton, Norsk Hydro) нарушает одно из них.

Почти все HEX-редакторы выглядят как унылый список байтов, в котором невозможно найти ничего интересного. Но достаточно добавить цвета — и человеческий мозг сам начнёт замечать магические сигнатуры, последовательности чисел, сжатые данные и даже скрытые изображения.

В этой статье будет рассмотрено, как работает подсветка байтов и какие hex-редакторы поддерживают это.

Bash прощает многое: можно писать кривые скрипты годами, и они будут работать. Кривизна вылезает, как правило, в самый неподходящий момент.

В статье рассмотрим пять ошибок, которые встречаются даже в проектах с опытными админами, потому что поведение Bash в этих местах неинтуитивно и плохо документировано в одном месте.

Я выпал из IT на месяц. Причина банальна, но сурова – капитальный ремонт. По квартире проложено пара километров кабеля, из них 600 метров витой пары для шины управления, на полу разложен макет двух щитов по 54 модуля общей стоимостью под 150 тысяч рублей – и чем глубже я лезу в ПУЭ и считаю сечения, тем чётче одна мысль: если бы инженеры-электрики проектировали системы так же, как мы, разработчики, проектируем распределённые приложения – мы бы все давно сгорели заживо.

Если твой агент обвешан пошаговыми инструкциями и десятком узких инструментов под каждый шаг — он, скорее всего, работает хуже, чем мог бы. Звучит контр‑интуитивно, но это прямой вывод из инженерных постов Anthropic за последний год: чем умнее становится модель, тем сильнее прежняя обвязка её сдерживает.

За год правила производства агентов пересобрались. Появилось семь отдельных дисциплин. Это первая из двух частей: здесь — четыре дисциплины‑фундамента, на которых держится рабочий агент, а не демка. И три из этих четырёх — не про то, что добавить, а про то, что убрать лишнее и довериться модели.

Написал агента который за ночь переписал 100 тестов с Mockito на MockK, а за следующую — исправил 1700 ошибок линта.

Спойлер: секрет не в крутом промпте, а в правильно выстроенном цикле — чётком DoD, автоматической проверке результата и обратной связи с моделью.

Каждый процесс в вашей компании — наследие прошлого. Жёстко? Возможно. Но логика верна. Каждый бизнес-процесс, который ваша организация выполняет сегодня, был спроектирован для мира без ИИ. Всё — от цепочек согласований до последовательностей передачи задач и обработки исключений — было построено на человеческом суждении. И всё это было выстроено вокруг предположения, что программное обеспечение может автоматизировать задачи, но координировать работу будут люди. Это предположение больше не работает.

После выхода Claude Opus 4.7 стало очевидно, что агент технически быстрее меня. А 28 мая Anthropic выпустила Opus 4.8 с теми же ценами, заметно лучшим coding/agentic-скором и новой возможностью держать в голове миграции на сотни тысяч строк

Знает он, кажется, всё. Все фреймворки, все паттерны, всю историю последних пятнадцати лет на StackOverflow и GitHub. По объёму знаний это легко сеньор, местами принципал

Но при всём этом ему не хватает трёх вещей

Привет, Хабр. На связи Александр Сахаров, директор по работе с партнерами компании "Диасофт". Про вайб-кодинг сейчас говорят так, будто индустрия уже все решила. Спойлер: не решила. Из всех разговоров осели три самых громких тезиса, и каждый при ближайшем рассмотрении ломается в конкретной точке.

Кому лень читать лонгрид, полная запись беседы лежит на Youtube. Спорить и задавать свои вопросы приходите в Telegram-канал Департамент разработки, где собирается сообщество разработчиков.

Знакома ли вам ситуация, когда никак не получается найти нужный чат в истории Cursor, Codex или Claude Code? Или когда чат настолько вырос, что запустилось сжатие контекста, а важные факты и промежуточные результаты потерялись?

Основной интерфейс взаимодействия с агентом — чат. Такой chat-first подход удобен как входная точка, но плохо подходит на роль рабочей среды для долгоживущих проектов и разработки фич, состоящих из нескольких задач. В чате контекст постепенно расползается: исходный запрос, уточнения, ограничения, промежуточные решения, логи, ошибки, результаты проверок и финальные артефакты оказываются в одной линейной истории.

Агенты очень хорошо работают с файлами: они прекрасно ориентируются в коде, зависимостях, правилах проекта (AGENTS.md) и навыках (skills/). Нативные инструменты любой среды агентной разработки заточены на эффективный поиск информации и другие операции с файлами. Так почему бы не использовать файлы и для хранения контекста задач?

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

Создаю собственный DSL на C#: рассказываю о том, как написать парсер, и как его оптимизировать. Так же покажу как работает обещанный DFA.

Представьте себе махину высотой 80 метров, где выплавляется чугун: основной процесс проходит непрерывно (вообще без перерыва, даже на обед). Это доменная печь (домна) на металлургическом заводе. Домна — это большая вертикально расположенная шахтная печь круглого сечения, сужающаяся сверху и расширяющаяся в средней части, окружённая стальным кожухом — бронёй, футерованной внутри огнеупорным кирпичом. Кожух от перегрева защищает система охлаждения — холодильные плиты между огнеупором и кожухом. Такие гиганты сразу строят под конкретный технический процесс, обвязывают нужными датчиками и запускают в работу без погружения в детали.  И печь работает годами или десятилетиями и более.

Но время идёт, технологии совершенствуются. У нас, промышленников, появляются возможности внедрить какое-то улучшение на производстве — где-то оптимизировать процесс и сэкономить. Вот только как провернуть такое с 80-метровой печью, всегда наполненной жидким раскалённым металлом?

Меня зовут Евгений Щелоков, начальник участка доменной печи № 3 ЕВРАЗ ЗСМК.  Я расскажу, как мы в ЕВРАЗе модернизировали систему автоматического распределения вдувания пылеугольного топлива (ПУТ) по фурменным линиям, что в результате позволило нам снизить (и довольно существенно) расход дорогого кокса. Если интересно, как можно применять IT для такой узкой и непростой цеховой задачи, — приходите за подробностями под кат.

Claude Code у меня появился в марте 2025-го. Точную неделю не помню — в какой-то момент он у меня просто стал инструментом по умолчанию, и я с ним отработал примерно год.

Это не «AI убил программирование» и не «AI = x10 продуктивность». И то и другое — пустое. Реальность скучнее и интереснее одновременно.

Сразу важная оговорка: я использую Claude Code на максимум. Не «иногда», не «когда подходит» — постоянно, на каждой задаче. Если что-то можно сделать через него, я делаю через него. Под него подстроены CLAUDE.md, hooks, skills, slash-команды, два MCP-сервера. Это контекст для всех выводов ниже. Стек: Python, бэкенд, команда маленькая.

Где он реально помог

Массовые рутинные правки. Самое чистое попадание. Когда у тебя задача «во всех 47 эндпоинтах добавь параметр request_id в логи и пробрось его в нижний слой» — это его работа, а не моя. Открываю агента, описываю абзацем, прошу сначала план, смотрю план, говорю «давай» — и через минут десять у меня PR с тестами. По ощущениям часов тридцать-сорок за год сэкономил только на таких задачах.

Совет, который я выработал не сразу: на больших правках сначала только план, без кода. Если план мимо — лучше потерять минуту на новой просьбе, чем час на разгребании неверно сделанного.

Чтение чужого репозитория. Раньше я тратил полдня на «понять, что тут вообще происходит». Сейчас открываю агента и говорю: «прочти структуру, расскажи как устроена аутентификация». Через минуту — приличный пересказ с указанием файлов.

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

Каждый, кто пробовал создавать текстовые RPG или симуляторы на базе LLM (будь то GPT-4, DeepSeek или локальная 70B), сталкивался с проблемой «Yes-And» проклятия. По своей природе современные языковые модели — это идеальные импровизаторы. Они обучены поддакивать пользователю и развивать его мысль.

В контексте игры это превращается в легальные читы. Игрок пишет: «Я достаю из кармана дымовую шашку и кидаю в охрану» или «Вообще-то я полковник ФСБ, пропустите». Что делает классический AI GM? Он послушно кивает: «Охрана кашляет в дыму, вы проходите», даже если по Game State игрок — бродяга в одних трусах, у которого в инвентаре только ржавый гвоздь.

Меня зовут Алексей, я профессиональный 1С-разработчик, но в свободное время создаю архитектуру инди-системы на Flutter и Python. Сейчас я развиваю проект нарративной AI-driven RPG "Стирая Грань" (анг. — Beyond the Verge).

systemd unit‑файл часто начинается с пары строк из чужого примера, а заканчивается сервисом, который странно рестартует, пишет логи куда попало и работает с лишними правами.

В этой статье разбираем, как собрать unit‑файл для своего Linux‑сервиса: от минимального скелета до production‑настроек с рестартами, зависимостями, hardening‑параметрами, лимитами ресурсов и journald.