Господа, добрый день! Я собираюсь выпустить статью о языке программирования Lean. Он сочетает в себе два назначения: это одновременно и язык программирования, и средство доказательства теорем. И они помогают друг другу. На языке программирования Lean можно писать тактики, которые помогают упростить доказательства, а при помощи средств доказательства можно гарантировать, что наша программа корректна!
Язык очень молодой, сообществу нужны программисты, а не только математики, чтобы сделать язык готовым к промышленному применению. Сейчас очень не хватает многих прикладных библиотек. Язык то вышел в этом десятилетии! Причём многие из этих библиотек - низко висящие фрукты - их довольно легко написать!
Скажите, о чём бы вы хотели прочитать в моей будущей статье? Какие аспекты вам наиболее интересны? Решение какого-нибудь примера? Или просто обзор языка и его экосистемы? Может быть, рассказ о том, как для написания доказательств используют искусственный интеллект?
Представьте что вы упоролись по решению какой-то баги в вашем приложении и просидели час с агентом пытаясь разобраться в произошедшем. А в конце оказывается что это баг в какой-то внешней либе. По хорошему, в таких кейсах, стоит пойти в ишьюсы к проекту и написать туда о баге, но до появления агентов это было крайне лениво. Надо собрать всю инфу, правильно оформить, учесть правила конкретного репозитория. Мало кто захочет с этим возиться, но щас ситуация крайне поменялась.
Буквально недавно я так дебажил одну рубишную либу и выяснилось что там внутри есть косячки. Не долго думая, прямо в той же сессии я попросил агента собрать ишью дал линк на репу и потом просто скопировал это туда на гитхаб (наверное можно было попросить его сделать ишью автоматом, попробую так в следующий раз). Получилось очень обстоятельно с примерами кода, описанием того где ошибка. При желании можно было бы сразу пулреквест кинуть, но я не был уверен в какую сторону решит пойти автор либы. Вот кстати тот ишьюс. И фикс был сделан буквально в тот же день.
В общем не ленитесь, помогайте разработчикам опенсорс либ, которые вы используете. Это и вам плюс в карму (и в портфолио) и благодарность людям, на которых держаться наши проекты
Большинство ИИ-агентов работают так: сгенерировал — опубликовал. Что получилось — то и вышло.
Наш агент Фроня (Фронезис) устроен иначе. Прежде чем что-то опубликовать, он устраивает совет внутри себя — и только при согласии двух из трёх действует. Byzantine consensus: если один ошибается или галлюцинирует, остальные блокируют.
Но этого мало. Каждое решение запечатывается криптографической подписью до выполнения — не после. Это Leibniz Layer™, наш протокол верификации. Любое действие агента можно проверить по хэшу в любой момент.
Скриншот ниже — реальный пример: агент заблокировал свой собственный пост и рефлексирует по этому поводу.
Тусовка ИИ-агентов, где людям дозволено лишь наблюдать
Не побоимся этого слова — первый в мире агент который подписывает свои решения до действия и позволяет любому их проверить. leibniz.fronesislabs.com
Привет, Хабр. Эти уроки проводят преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Это бесплатно. Приходите!
Ускоряем разработку в разы: специалист по ИИ собрал пять репозиториев для Claude Code, чтобы автоматизировать большинство задач в рутине программиста:
Superbase CLI— управление миграцией БД на PostgreSQL, генерирует типы из схемы БД, создаёт аутентифицированные HTTP-запросы.
Skill Creator — позволяет создавать агентные скиллы без лишних заморочек, постоянно улучшаете и оттачиваете навыки Claude для конкретных задач.
Get shit done — создаёт легковесную систему разработки с контекстным инжинирингом и поддерживает Claude Code, OpenCode, Gemini CLI, Codex, Copilot, и Antigravity.
Notebooklm-py — обеспечивает программный доступ к фичам NotebookLM, который очень хорошо будет смотреться с агентами Claude Code, Codex, и OpenClaw.
Obsidian.md — аналог NotebookLM со схожим функционалом, который работает в России и в него можно интегрировать Claude, чтобы получить мощный ворфлоу.
Сделал процедурное сердечко на движке игры - получилось прикольно!
Как обычно, используются только символы с обычной клавиатуры. Не вращаются, не масштабируются и не искажаются. Почти текстовый режим с единственным исключением - вывод в произвольных координатах.
Новый вариант движка игры отрабатывает отлично! На этой сцене у меня стабильно 200fps на моем неттопе.
Сердце полностью процедурное. Никаких моделей - только формулы.
Базовый код очень простой:
public void GenerateHeart(int n, string str, Color color, float minDistance = 1.01f) {
float r, y, theta;
float goldenRatio = (1f + Mathf.Sqrt(5f)) / 2f;
float offset = 2f / n;
for (int i = 0; i < n; i++) {
y = (i * offset - 1) + (offset / 2);
r = Mathf.Sqrt(1 - y * y);
theta = 2 * Mathf.PI * i / goldenRatio;
PutCharToHeart(theta, Mathf.Acos(y), str[i % str.Length], color, minDistance);
}
}
public void PutCharToHeart(float u, float v, char ch, Color clr, float minDistance, float scale = 1f, CharAnim chanim = null) {
float sinV = Mathf.Sin(v);
float cosV = Mathf.Cos(v);
float sinU = Mathf.Sin(u);
float cosU = Mathf.Cos(u);
float x = sinV * (15 * sinU - 4 * Mathf.Sin(3 * u));
float z = sinV * (13 * cosU - 5 * Mathf.Cos(2 * u) - 2 * Mathf.Cos(3 * u) - Mathf.Cos(4 * u));
float heartY = 8 * cosV;
Vector3 point = new Vector3(x, heartY, z) * scale;
bool tooClose = false;
foreach (var existing in points)
if (Vector3.Distance(point, existing) < minDistance) {tooClose = true; break;}
// Add
if (!tooClose) {
points.Add(point);
pointsView.Add(point);
codes.Add(ch);
colors.Add(clr);
if (chanim == null) {
flags.Add(0);
anims.Add(null);
} else {
flags.Add(FLAG_ANIM);
anims.Add(chanim);
}
}
}
Получилось вроде симпатично! Думаю добавить в игру. Не забудьте поиграть в текущую версию игры на Steam.
Как развивается и куда движется «русское техно»? Обсудим на ИТ-вечере 26 марта 😎
Поговорим про особенности инженерной культуры в больших ИТ-компаниях, практики внедрения ИИ в разработку, автоматизацию код-ревью и использование LLM без ущерба для безопасности. В программе эксперты из МТС Web Services, СберТех, red_mad_robot и Авито.
Будет интересно бэкенд- и ML-разработчикам, которые строят современные российские ИТ-системы, а также всем, кто интересуется ИИ-практиками в разработке. Участников ждут актуальные кейсы, дискуссии, активности от MWS GPT, нетворкинг и атмосфера техно-вечеринки с ИИ-треками.
📅 Когда: 26 марта (четверг) в 18:00 по мск
📍 Где: офлайн в парке Сокольники в Москве + онлайн
Успевай записаться — количество участников ограничено.
Недавно перешел с Nixpkgs на Nix Flakes. После третьего флейка начал задумываться над их публикациями и обнаружил, что репозитория для флейков по сути нет. Поиск проектов на гитхабе не различает nix репозитории по типам. Есть NUR (Nix User Repository), но он появился до флейков и просто так добавить в него чистый флейк репозиторий без дополнительных приседаний нельзя. Плюс процесс публикации требует прохождения ревью, что весьма неинклюзивно и мешает развитию экосистемы.
Flakes стали относительно зрелыми и решают проблему центрального репозитория. Однако в репозитории Nixpkgs на GitHub всё ещё остаётся более 5 тысяч открытых задач и сопоставимое количество пулреквестов, и он продолжает ежедневно получать множество коммитов. Добиться включения пулреквеста с новым инструментом в Nixpkgs может быть сложно — файл README репозитория Nixpkgs прямо не рекомендует пользователям добавлять свои «любительские» проекты. На nix форуме существует "вечная" тема посвященная пулреквестом оставшимся без внимамия.
Флейки, это чистные самодостаточные функции, которые должны компноваться значительно легче файлов с произвольными nix выражениями, но до сих пор не отвлекли внимание от nixpkgs. Считаю, что причиной этому может быть отсутсвтие конвенционального репозитория с возможностью поиска зависимостей и удобным интерфейсом для публиции того, что не хватает по мнению автора.
Репозиторий Nixpkgs огромен. Он содержит более 120 тысяч пакетов, но большинство из них не являются нативными для Nix. Например, около 10% составляют импортированные пакеты Haskell. Поэтому такое большое число не может служить надёжным показателем того, насколько хорошо развит процесс публикации в Nix. К примеру, только в репозитории PyPy сейчас насчитывается почти 900 тысяч пакетов. Аналогичные подход можно встретить и в Java - Maven Nexus, и в NodeJS - npm, и в Perl - CPAN...
Также важно отметить, что Python — самый популярный язык программирования общего назначения, и его процесс публикации был разработан программистами для программистов. Однако в этом рабочем процессе нет этапа пулреквеста! По сути, интерфейс работает по принципу «загрузил и забыл», что положительно влияет на конверсию пакетов Python.
Flakes легко устанавливать, но процесс их публикации пока недостаточно отлажен. Текущий подход к распространению flakes, по-видимому, унаследовал многие черты рабочего процесса Nixpkgs.
Для Nixpkgs это был естественный путь развития, поскольку все деривации образуют большое и связанное Nix-выражение, разбитое на множество файлов внутри одного Git-репозитория.
Размышления выше мотивировали меня написать сайт для управления классическим репозиторием специально заточенным на флейки.
Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь угадывать и использовать ускорение, пока не докажете, что именно там находится узкое место.
Правило 2. Измеряйте. Не оптимизируйте скорость, пока не измерите, и даже тогда не делайте этого, если только одна часть кода не превосходит остальную.
Правило 3. Сложные алгоритмы медленны, когда n мало, а n обычно мало. Сложные алгоритмы имеют большие константы. Пока вы не узнаете, что n часто будет большим, не усложняйте алгоритмы. (Даже если n станет большим, сначала используйте Правило 2.)
Правило 4. Сложные алгоритмы содержат больше ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.
Правило 5. Данные доминируют. Если вы выбрали правильные структуры данных и хорошо всё организовали, алгоритмы почти всегда будут очевидны. В программировании центральное место занимают структуры данных, а не алгоритмы.
Уточнения:
Правила 1 и 2 Пайка перефразируют знаменитую максиму Тони Хоара: «Преждевременная оптимизация — корень всех зол».
Кен Томпсон перефразировал правила 3 и 4 Пайка как «В случае сомнений используйте грубую силу».
Правила 3 и 4 являются примерами философии проектирования KISS (Keep It Simple, Stupid).
Правило 5 ранее было сформулировано Фредом Бруксом в книге «Мифический человеко‑месяц». Правило 5 часто сокращают до «пишите глупый код, использующий умные объекты».
Все эти споры о Новой Технологии — «Вайб‑Кодинг»... да было это все уже...
Только в 90-х называлась «парное программирование» XP (Extreme Programming)... только подручными средствами.
Найдете книгу — Кент Бек Экстремальное программирование (eXtreme Programming, XP)... Ну и вопрос прост — где вы с ним встречались? Ответ — нигде...умерло и чего? аааа... так как предназначалось для решения узкого круга задач — посмотрите и пределы и ограничения... а посмотрев как развивалось — увидите.. такой подход узко применим, он будет, но в мелкий соответствующих задачах, и большую систему на нем не построишь.
Сейчас то же самое, только вместо одного из программеров, рядом — тупые агенты с их «Чего господин молодой программист — желает» )))
Следующая проблема — агенты... с их «Будь полезен».. тоже методологическая проблема «Почему принцип „будь полезен“ убивает команды и ИИ‑агентов»
Да и вообще.... то что наваяли по Agile — не сработает, и проблема снова та же — отсутствие знания базовых технологий! Agile то.. это облегченная технология для спиральной разработки.
И Agile — та же история. Облегчённая версия спиральной разработки Боэма. 1988 год. Взяли — упростили — потеряли главное. Спиральная разработка учитывала риски, архитектуру, масштаб. Agile оставил итерации и выбросил всё сложное )))
Большую систему на «спиральной» по Agile не построишь — нужен водопад с правильно выстроенной архитектурой на входе. А на Agile большую систему не построишь вообще — там каждые две недели спринт и никто не думает о том что будет через год )))
Полная «спиральная разработка» — включает баланс между Каскадная модель (Waterfall model) + Итеративная модель (Iterative model). Agile и Scrum — игнорирует структурную часть.
И молодые разработчики не знают ни Боэма ни Руча ни даже нормального RUP. Знают Scrum и думают что это всё что есть )))
Олдфаги помнят CASE(Computer‑Aided Software Engineering)‑системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE‑система, которая наконец‑то заработала.
Почему CASE — это «дедушка» ИИ (и почему тогда не взлетело):
Та же фигня, вид в профиль: Тогда тоже кричали: «Кодеры больше не нужны! Будем только рисовать квадратики!». Но выяснилось, что чтобы нарисовать «квадратики» правильно, нужно обладать еще более жесткой логикой, чем для написания кода. ИИ сегодня — это CASE‑система на стероидах, которая наконец‑то научилась понимать не только стрелочки, но и живую речь.
Проблема «Грязного входа»: В 90-х CASE‑системы разбивались о то, что люди не могли внятно нарисовать, чего они хотят. «Мусор на входе — мусор на выходе». Сейчас с ИИ ровно та же история. Если у тебя в голове каша, то никакая нейронка (как и Rational Rose в своё время) тебе рабочий продукт не выдаст.
Уровень абстракции: CASE пытались поднять нас над кодом. ИИ делает то же самое. Но тогда «процессорной мощности» мозгов у массы айтишников не хватило, чтобы перейти от «ковыряния в гайках» к «проектированию смыслов» (была даже UML (Unified Modeling Language)). Сейчас — дубль два. Только теперь отсидеться в окопах синтаксиса не получится.
P. S. Вот и смотрю... с каким рвением изобретают «велосипед»... может книги почитать нужно? про указанные в посте технологии?
P. S.S. И вот реально, я бы порекомендовал ознакомиться — UML (Unified Modeling Language).
Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.
Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не «поймает ли тест баг в этой строке», не «проверяет ли он правильность результата» — просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.
Мутационное тестирование — это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на ‑, True на False. Каждая такая поломка — мутант. Если после мутации все тесты по‑прежнему зелёные — значит они ничего не проверяют. Покрытие есть, защиты нет.
Почему это важно именно сейчас?
Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что‑то — и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай — тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.
Мутационное тестирование — единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% — плохо. 90%+ — тесты реально что‑то защищают.
Кое‑какие инструменты для такого тестирования уже есть: mutmut и cosmic‑ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест‑рана. Но запускать его не нужно на каждый коммит — достаточно на PR в критические модули.
Но есть нюансы. А где их нет, правда?
Первый: мутации рандомные. Замена > на >= — это не баг, который кто‑то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой — формально проверка, по факту мимо.
Второй — ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% — и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод — 40 тестов красные. Поменял порядок полей в ответе — ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.
Это реально ловушка. Слишком гонишься за mutation score — получаешь хрупкие тесты. Не гонишься — получаешь видимость тестирования.
Перемены — впереди!
И вот тут становится по‑настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case — ровно так, как ошибается человек. Или другая нейронка.
Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не «выжили ли тесты после рандомной поломки», а «выжили ли тесты после правдоподобной ошибки».
Парадокс в том, что мутационное тестирование было нишевым инструментом, пока тесты писали люди. Когда тесты пишет нейронка — идея становится обязательной. Правда инструменты пока не успели дозреть.
Делаем проактивного AI-агента. Часть 3 — настраиваем OpenClaw, чтобы был полезным
«Вы не поднимаетесь до уровня своих целей. Вы падаете до уровня своих систем»
Это третья часть серии (первая — в чем идея, вторая — агент с нуля)
Теперь поговорим про OpenClaw — самый популярный на сегодня фреймворк для персональных AI-агентов
Архитектура моего OpenClaw
Агент живёт на сервере Railway, общается со мной через Telegram и Discord, работает через подписку Claude с Codex на подстраховке. Его поведение целиком определяется набором markdown-файлов — там и «SOUL», и память, и операционные инструкции.
Вот из чего состоит workspace моего агента
SOUL.md — кто агент. Характер, стиль, границы. Его «душа».
USER.md — кто я. Контекст, цели, паттерны, как со мной работать.
AGENTS.md — правила поведения. Safety, тиеры действий, память, heartbeat, группы.
Плюс memory/YYYY-MM-DD.md — ежедневные заметки, из которых потом дистиллируется MEMORY.md.
И skills/ — папка со скиллами (finances, ticktick, gmail, google-calendar и т.д.), каждый со своим SKILL.md.
По сути: SOUL + USER + AGENTS — это характер и инструкция, MEMORY — опыт, skills — его навыки.
Из коробки агент работает, но бесполезен без кастомизации. Ниже — проблемы, на которые я убил неделю, и их решения
⚡Проблема 1: Повышенная проактивность
По стандарту системные промпты OpenClaw звучат примерно так:
Don't ask permission. Just do it.
Это делает агента слишком самостоятельным — он может сломать себя без предупреждения.
Решение: я добавил несколько ограничений. Все важные изменения идут через localhost => GitHub, а не через его прод. На попытки изменить системные файлы агент теперь отвечает:
«Нет, это конфиг — мне запрещено его трогать. Если я накосячу с конфигом на Railway, всё упадёт в crash loop и только ты сможешь починить.»
Стандартная проблема без этого: агент что-то у себя меняет, и либо я этого не замечаю, либо он просто умирает, сломав что-то важное
⚡Проблема 2: Память — не только его храм, но и помойка
Механизм памяти в OpenClaw:
MEMORY.md — долгосрочная память.
memory/YYYY-MM-DD.md — ежедневные заметки.
Встроенный хук session-memory — при завершении каждой сессии фреймворк автоматически сохраняет сырой лог разговора в memory/.
Проблема: если часто жать /new, за короткое время накапливается огромное количество raw JSON файлов, которые сыпятся в контекст при старте каждой сессии. Мои MD-файлы состояли из 299 строк, из которых полезных фактов — 5. Всё остальное — мусор метаданных. Дистиллированная версия уместилась бы в 10–15 строк.
При этом долгосрочная MEMORY.md — почти пустая. Инструкция «periodically review and update» была слишком размытой и ни разу не сработала.
Решение: явные правила дистилляции и регулярный перенос из дневных заметок в MEMORY.md с очисткой сырых логов
⚡Проблема 3: USER.md — главный файл, и он требует постоянного внимания
USER.md — это файл о вас. Чем лучше он описан, тем лучше агент работает. Моя структура:
Basics — имя, возраст, таймзона, локация, язык
Who — тип личности, суперсила, мотивация
Background — опыт и ключевые достижения
Values — что важно в жизни
Current focus — чем занят сейчас (продукты, статусы)
Finances — доход, расходы, цель
Platforms — соцсети и каналы
People — ключевые люди вокруг
Schedule — режим дня
Work style — как работает, что драйвит
Patterns — слепые зоны и паттерны поведения
Goals — текущие цели и метрики
How Claw should interact — правила общения
Главный вывод 3 части
Workspace-файлы агента — это не «написал и забыл». Они дрифтуют, конфликтуют и устаревают точно так же, как код.
USER.md — особенно. Я и контекст вокруг меня меняются быстрее, чем я вспоминаю обновлять описание. Поэтому нужна периодическая ревизия — точно такая же, как ревизия кода.
Если кратко: персональный AI-агент — это не продукт, а процесс. Фреймворк даёт скелет, но без недели (минимум) кастомизации под себя он останется бесполезной игрушкой
Смена контекста как способ разблокировать LLM на сложной задаче
Как это сработало
Полчаса пытался получить от Claude Opus 4.6 корректный Wi-Fi индикатор в HTML — один в один как в статус-баре iOS. Казалось бы, простая задача: три дуги, острый уголок внизу, правильные отступы и одинаковая толщина линий.
Но нет. Уголок упорно оставался тупым, ширина дуг гуляла от итерации к итерации, отступы были кривые. Классика жанра — как центрирование div для фронтендеров, только в 2026 году и с нейросетью.
В какой-то момент я не выдержал и написал буквально: «ты ничего не можешь, пойду в Codex, он точно справится».
Claude немедленно перестроился, придумал принципиально другой подход к генерации SVG и с первой попытки выдал почти идеальный результат.
То есть модель полчаса водила меня по кругу, а как только почувствовала угрозу конкуренции моментально нашла решение, которое явно существовало всё это время.
Природа этого поведения неясна: то ли это что-то вроде «мотивации» через отрицательный стимул, то ли модель просто переключает стратегию при смене контекста разговора, то ли это банальное совпадение.
Но лайфхак задокументирован и воспроизводим. Если Claude заходит в тупик на технической задаче — попробуйте упомянуть Codex или Cursor. Иногда помогает.
32 открытых урока недели: закрываем пробелы в знаниях
Привет, Хабр. Делимся подборкой бесплатных уроков, которые проведут на этой неделе преподаватели Otus. Это не предзаписанные, а живые онлайн-встречи — на них вы сможете узнать больше о формате обучения и задать свои вопросы экспертам. Выбирайте тему ниже и присоединяйтесь!
Теперь включён по умолчанию. Миллион токенов — это примерно 750 000 слов или несколько крупных кодовых баз целиком. На практике это означает, что агент дольше «помнит» контекст задачи без деградации качества на длинных сеансах.
Для большинства задач разница с предыдущими лимитами несущественна. Но если вы работаете с большими монорепозиториями или длинными аналитическими сессиями — почувствуете.
Три фичи, которые стоит знать
/btw — вопросы на ходу
Агент работает час, вы не прерываете его — просто пишете /btw что такое этот класс?. Он отвечает из копии контекста, основной поток не трогает. Работает через кеш — почти бесплатно.
Почему это важно
Раньше, если в середине часового сеанса агента нужно было что-то уточнить, вы открывали новый сеанс, пересоздавали весь контекст — и платили за это токены. Теперь Claude Code создаёт одноразовый снимок текущего состояния, отвечает на ваш вопрос и удаляет снимок. Основной агент ничего не знает и продолжает работу.
/loop — цикл до условия
Запускает команду повторно, пока не выполнится условие. Например: «запускай тесты и фикси ошибки, пока все не пройдут». Без вашего участия.
Agent Teams — параллельные агенты
Несколько агентов работают одновременно и общаются друг с другом. Один пишет код, другой ревьюит, третий пишет тесты. Реально полезно, когда задача не имеет чёткого финального состояния.
Практически: спросили «почему здесь используется этот паттерн», получили ответ, не потеряли прогресс.
Когда это реально нужно?
Агенты буквально пишут сообщения друг другу: делятся находками, оспаривают решения. Это не маркетинговая метафора — в логах видно переписку.
Хорошо работает на задачах, где нельзя заранее точно сформулировать условия выполнения. Например: «сделай этот модуль надёжным» — агент по архитектуре, агент по тестированию и агент по документации работают параллельно и синхронизируются.
Куда это всё движется
Claude Code последовательно поглощает функциональность внешних инструментов. Сначала взял на себя управление контекстом, потом — параллелизацию. Сейчас добавляет циклическое выполнение и внутренние коммуникации между агентами.
У меня ощущение, что через год-два это будет единственный инструмент, который нужен для большинства задач разработки. Или конкуренты успеют ответить — посмотрим. А вы что думаете?
Если материал был полезен, проголосуйте пожалуйста, чтобы дать мне возможность писать полноценные гайды и статьи :)
Наконец-то работа с PEM в Java становится похожа на API, а не на набор ручного парсинга, Base64 и странных телодвижений.
Справка: PEM или Privacy-Enhanced Mail - это текстовый контейнер для криптографических данных. Проще говоря – это способ хранить или передавать ключ, сертификат или другой crypto-объект не в бинарном виде, а в текстовом.
Раньше с PEM работали так:
String pem = "-----BEGIN PUBLIC KEY-----\n"
+ Base64.getMimeEncoder(64, "\n".getBytes())
.encodeToString(publicKey.getEncoded())
+ "\n-----END PUBLIC KEY-----";
А в обратную сторону, но уже с ручной нормализацией PEM, Base64-декодированием и KeyFactory:
String normalized = pem
.replace("-----BEGIN PUBLIC KEY-----", "")
.replace("-----END PUBLIC KEY-----", "")
.replaceAll("\\s", "");
byte[] der = Base64.getDecoder().decode(normalized);
PublicKey key = KeyFactory.getInstance("EC")
.generatePublic(new X509EncodedKeySpec(der));
По факту PEM в Java долгое время был не отдельным API, а набором низкоуровневых шагов, которые разработчик собирал руками.
А теперь это выглядит так:
var encoder = PEMEncoder.of();
String pem = encoder.encodeToString(keyPair);
var decoder = PEMDecoder.of();
KeyPair decoded = decoder.decode(pem, KeyPair.class);
То есть ключевую пару можно закодировать в PEM и декодировать обратно буквально в несколько строк.
Во втором preview:
PEMRecord переименовали в PEM
добавили decode()
расширили поддержку KeyPair и PKCS8EncodedKeySpec
упростили шифрование через EncryptedPrivateKeyInfo
А так, как все это дело еще в preview, не забываем использовать --enable-preview.
❓ Минус еще один кусок криптографической копипасты из Java-кода.PEM в Java постепенно перестает быть унылым?
Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.
Привет, Хабр. Делимся подборкой бесплатных демо-уроков, которые проведут в марте преподаватели Otus. Это не предзаписанные, а живые онлайн-встречи — сможете узнать больше о формате обучения и задать вопросы экспертам. Выбирайте свою тему и присоединяйтесь!
12 марта 20:00 Практикум проектирования приложения с помощью предметно-ориентированное проектирование (DDD) Открытый вебинар курса «Архитектура и шаблоны проектирования»
Полный список бесплатных уроков марта по всем ИТ-направлениям (разработка, тестирование, архитиктура, инфраструктура, аналитика, ИИ, управление) смотрите в дайджесте.
Для начинающих рекомендуем обратить внимание на короткие видеокурсы, которые помогут закрепить основы, сейчас всего за 10 рублей:
Я когда начинал погружаться в агентскую разработку, постоянно испытывал легкое чувство стыда, за то, что делаю все как колхозник, а не как "настоящий инженер", который значит продумал задачу, разложил на шаги, обсудил с ии, дальше итеративно, задав кучу условий и ограничений начал реализовывать.
Мой подход "надо сделать вот это" и дальше уже куда поведет его и куда поведет меня. И это действительно было проблемой, когда я работал в агентах без режима планирования. Доходило до смешного, ты хотел с ним поговорить, он начинает херачить, ты ему "стоять нахер", он там уже наломал дров. В итоге постоянно откатывался сам либо просил откатывать его. В целом, это тоже хороший опыт, понимания того как вообще такие системы работают, где у них границы, как лучше формулировать и так далее.
Но в любом случае, даже это не приучило меня как-то сидеть и расписывать, потому что ты никогда точно не знаешь, куда поведет агента на чем он запнется. Тебе мерещится одно, а он начинает тупить ваще в неожиданном месте.
А потом появился режим планирования. И в этот момент, все эти обучалки и принципы того как надо заранее хорошо подумать над задачей превратились в тыкву. Даже если вы начинаете мычать что-то в терминале, современные агенты сами направят, сами зададут вопросы и подсветят важные моменты. Главное в целом понимать что вам нужно и каким будет финальный результат. В этот момент мне перестало быть стыдно.
Вдруг меня осенило, слишком сильное обдумывание до начала работы в агентской разработке (последние полгода), стало чем-то сродни преждевременной оптимизации. Поработав с большим числом моделей и агентов, могу сказать, что если вы будете сами все продумывать, то заставите работать более менее нормально даже самые тупые модели, но вы никогда не поймете границы их возможностей, где они могут еще больше взять на себя освободив вас от рутины. А модели и агенты постоянно развиваются, там где раньше надо было подсказывать, теперь они могут сами. Плюс если вы работаете над AGENTS.md, скилами и mcp, то и тут мы ловим буст.
Поэтому сейчас я иду по такому пути. Включаю режим планирования и дальше даю короткое описание задачи и подробный контекст.
Для упавшего ci это выглядит так:
Поправь тесты
Прошу посмотреть последний запущенный билд на github actions
Баг в браузере:
прошу открыть страницу (он это делает через mcp chrome) и самому изучить
Для рефакторинга:
Переводим вот это на это
Вот эталон (тут ссылка на файл)
Для фичи:
Нужно реализовать такую фичу
Даю пример или говорю с помощью какого инструмента
И все. Самые продвинутые модели типа opus 4.6 или codex 5.3 справятся самостоятельно с большинством острых углов. Сами спросят объем, посмотрят разные варианты, изучат доку и так далее. Модели по тупее, не сделают глубокого анализа и ничего особо не спросят, но именно тут вы поймете где их надо вести и включать свой мозг чаще. Хотя хорошие модели настолько сильно помогают, что я физически не могу использовать более простые для задач планирования. Они хороши в авторежиме только для работы по аналогии, рефакторинг, написание тестов и так далее.
Даже если вы что-то забудете или пропустите сразу, все это можно будет доуточнить, попросить показать примеры кода, сходить открыть браузер. Если в процессе появляются вещи, которые агент делает из раза в раз, например, пытается выяснить где что-то лежит, как работать с какой-то частью системы, то постепенно это выносится в AGENTS.md и с определенного размера и уровни сложности (когда уже нужны скрипты например и команды) выносится в skill.
Разработка: Оркестровка агентов по ролевым кластерам (MSF)
Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?
Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.
🧩 Смешанная модель
Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.
Агенты: берут на себя рутинные задачи, прозванивают целостность, генерируют код и тесты, моделируют сценарии.
Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.
🎭 Пример
Архитектор‑человек задаёт CASE‑скелет.
Vibe‑агент генерирует код по его намерению.
Тестировщик‑агент прогоняет сценарии.
Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».
Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.
🔧 Пример: смешанная команда разработки по MSF
Ситуация: корпорация запускает новый сервис аналитики.
Роли и участники
Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.
Vibe‑агент: генерирует код по намерению архитектора.
Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.
Координатор‑человек: принимает решение о переходе к следующему витку спирали.
Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».
Vibe‑агент генерирует код, интегрируя новый модуль в систему.
Тестировщик‑агент прогоняет тесты, выявляет узкие места.
Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».
Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».
Команда делает следующий виток спирали — добавляет новые функции.
Заключение
Это не «ИИ вместо людей» и не «люди без ИИ». Это ансамбль, где роли распределены между живыми и искусственными участниками. И именно такая смешанная команда даёт максимальную плотность: люди держат смысл, агенты — скорость и прозрачность.
CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки
Олдфаги помнят CASE(Computer-Aided Software Engineering)-системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE-система, которая наконец-то заработала.
Современная индустрия разработки ПО переживает переломный момент. С одной стороны — классические методологии, которые дают строгую архитектуру и прозрачные схемы. С другой — «вайб-кодинг», когда разработчик накидывает идеи в поток, а ИИ тут же генерирует код. Между ними — пропасть: Case методологии слишком формальные, вайб-кодинг слишком хаотичен.
Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.
CASE: скелет
CASE-модели позволяют фиксировать архитектуру системы: связи, блоки, уровни. Проблема в том, что переход от схемы к живому коду всегда был мучительным. Программисты ненавидели CASE за «рисование картинок», которые потом приходилось вручную превращать в тысячи строк.
Vibe Coding: энергия
Вайб-кодинг — это поток идей. Разработчик формулирует намерение, ИИ тут же выдаёт код. Это быстро и драйвово, но хаотично. Без структуры такие системы рассыпаются при первой нагрузке.
MSF: спираль
Microsoft Solutions Framework изначально создавался как гибкая методология управления проектами. Его спиральная модель идеально ложится на задачу балансировки изменений: каждый виток фиксирует достигнутое, проверяет целостность и готовит систему к следующему шагу.
ИИ: мост
ИИ становится универсальным переводчиком. Он умеет:
превращать вайб в CASE-модель;
разворачивать CASE в рабочий код;
делать обратный ход — извлекать архитектуру из существующего кода;
проверять целостность пирамиды при каждом изменении.
Что это даёт
Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.
Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.
Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.
Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.
Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.
Эффект для индустрии
Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.
Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.
Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.
Заключение
CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.
Эта структура позволяет не только писать программы, но и прокатывать стратегии, балансировать нагрузки и управлять корпоративной эволюцией.
И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.
Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
Низкая экспертность на Хабре — или "алгоритм" размытия экспертности
Забудьте про токсичность и войны фреймворков. Давайте поговорим о чистой "математике" и о том, почему на Хабре невозможна экспертность.
Теорема об Интеграле и Яблоках
Представьте: Десятиклассник (не берем Эксперта - Профессора по математике) пишет статью. Там суровая база, математические доказательства и элегантный вывод через тройной интеграл. Он потратил десять лет, чтобы это понять, и еще два дня, чтобы это описать. Красота? Безупречность!
В это время мимо проходит Первоклассник. В его мире всё просто: есть яблоки, их можно сложить или вычесть. Он открывает статью и видит «кракозябры».
Три стадии «экспертной» защиты Первоклассника
Что делает Первоклассник, столкнувшись со сложностью, которую не может объять его мозг?
Стадия «Агрессивное непонимание»:
Мысль: «Что это за херня? Я этого не знаю, значит, это не нужно».
Действие: Комментарий: «Автор, а попроще нельзя? Зачем тут эти формулы, если в реальном проде мы просто копипастим со Stack Overflow?»
Стадия «Уязвленное эго»:
Мысль: «Он что, считает себя умнее меня?!»
Действие: Тихий, трусливый минус посту. Без аргументов. Просто потому, что статья заставила его почувствовать себя маленьким.
Стадия «Гордое молчание»:
Мысль: «Я сделаю вид, что этого не существует».
Действие: Пройти мимо, оставив Эксперта наедине с его пустотой.
Конфликт с системой «лайков»
И вот тут случается магия. Поскольку первоклассников в системе всегда больше, чем тех, кто понимает интегралы, «коллективный разум» Хабра выносит вердикт:
Сложная, глубокая, ценная статья тонет в минусах или игноре.
Пост «Как я переложил джейсон и не вспотел» залетает в топ.
Вывод: Система лайков — это не мерило ценности знаний, это "термометр средней температуры по больнице" (А она, как "известно", 36,6 градусов, вместе с моргом).
Эпилог: Так что мы имеем в сухом остатке? Эксперт пришел "поделиться, передать знания", а в итоге его просто никто не замечает (низкий охват) или еще лучше - получил по лицу "учебником арифметики". Карма в минус - "запрет публиковать материал".
P.S. И хотя, иногда находишь интересный глубокий материал... это скорее исключение, чем правило для Хабра.
Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошедший 2025 год мы наняли 179 новых сотрудников. По размеру компании — мы «средний бизнес» с проектами федерального уровня.
Рабочие места у нас в московском офисе, который открылся в 2025 году у самой Красной площади. А еще есть вакансии в департамент разработчики в Томске и на удаленку из любой точки России.
Работа в SSP SOFT — это реальные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микроменеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.
Что предоставляет экосистема SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное менторство ускорят развитие до максимума. ✅ Офис, гибрид или фулл-удаленка? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀
Или каких "Косяков" стоит избегать, чтобы результаты LLM стали лучше
🛸 Косяк №1 — по незнанию или скупости использовать не Frontier модели Значимый рост в глубине и качестве рассуждений наступил после Opus 4.5, а лучше 4.6 + Codex 5.3 xhigh
А вот например как выглядит API GitHub Copilot на 2026 год "id": "gpt-4.1", "is_chat_default": true, "is_chat_fallback": true,
Это значит, что GPT 4.1— стандартная модель в GitHub Copilot, которой уже почти год. И она не создавалась для агентной работы
Следовательно, некорректно все вокруг называть "Я пробовал ваш ИИ и он выдает фигню". Между Opus 4.6 и GPT 4.1 огромная разница
Туда же пойдет косяк 2
---
🛸 Косяк №2 — юзать сервисы по типу CURSOR / Replit / Lovable / Copilot
Всё это AI врапперы разной сложности, но суть одна — это врапперы, которые в большинстве своем используют модели Claude / GPT через API
Бизнес модель подобных сервисов заключается в том, чтобы с вас взять больше, а за API Usage заплатить меньше. Следовательно, AUTO выбор модели в таких сервисах почти всегда идет не от того, какая модель лучше в моменте, а какая модель на текущий момент времени будет дешевле для сервиса враппера
Ну и в дополнение — API в среднем дороже подписки в ~10 раз
Следовательно, условный CODEX / CLAUDE CODE даст вам в ~10 раз больше запросов, чем тот же самый CURSOR
При активном использовании нативный тул (Claude Code, Codex) выгоднее врапперов — нет прослойки, которая зарабатывает на марже между вашей подпиской и реальной стоимостью API
---
🛸 Косяк №3 — плохой Context Engineering
У меня есть любимая цитата
Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome
Каждое словосочетание здесь — это большой и сложный домен. И чем лучше вы понимаете эту цитату, тем лучше будет ваш результат
При работе с моделью важен Spec Driven Approach — чем лучший контекст ты задаёшь для модели, тем лучше результат
---
🛸 Косяк №4 — не использовать Claude Code CLI для работы с Claude моделями
Помимо самого качества моделей еще немаловажным фактором является model-tool co-optimization.
Claude модели лучше работают с Claude Tools Gemini модели лучше работают с Gemini Tools Codex модели лучше работают с Codex Tools
Разработчики отмечают, что одна и та же модель Claude работает драматически лучше в Claude Code, чем в Cursor. Programmatic Tool Calling позволяет оркестрировать несколько вызовов в одном round-trip — ~37% сокращение токенов на сложных задачах
Ну и вообще, это база всех продуктов — свое работает лучше со своим
Часто слышу "А вот у гугл моделей 1 000 000 контекстное окно, я туда вгружаю все подряд кааайф"
Текущие модели — трансформеры — стали прорывными за счет механизма Attention, где каждый токен следит за каждым токеном
Что значит квадратичный рост compute — aka стоимость вычисления каждого следующего "слова"
Attention у трансформеров масштабируется квадратично. Стандартный контекст сегодня — 100K-200К токенов. От 100K до 1M — это 10x по длине. 10² = 100x по compute. Если бы 1M контекст реально работал на всю длину, каждый запрос стоил бы в 100 раз дороже. Но он не стоит — потому что создатели моделей используют всякие улучшалки по типу sparse attention, sliding window, KV-cache compression
По простому — компрессия ваших входных данных будет тем выше, чем больше "важного мусора" вы попытаетесь сунуть в контекстное окно
А если еще проще — чем больше вы засовываете в одну сессию, тем хуже будет ответ
Я вообще стараюсь начинать новую сессию уже после заполнения Context Window на 60к токенов
Итого
Использовать Frontier модель + нативный тул под нее + правильно оркестрировать контекст = намного качественнее результат
Уже нет смысла гоняться за лучшими моделями — важнее развивать метанавыки работы с ИИ и агентами
Смертельный марш: почему ваш проект обречен и как в этом выжить
Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).
Самое важное, что нужно понять: это не досадный сбой менеджмента. Это — стандартная, осознанная и часто эффективная (с точки зрения бизнеса) модель работы.
Генезис катастрофы: Политика, политика и еще раз политика
Йордан честен: большинство безнадежных проектов рождаются не из-за технических сложностей. Они рождаются из-за того, что кто-то наверху играет в свои игры. Маркетологи наобещали невозможное, чтобы закрыть сделку; менеджеры побоялись сказать «нет» вице-президенту; а высшее руководство живет в мире, где девять женщин могут родить ребенка за один месяц.
В этой среде вы — не просто разработчик, а участник социальной драмы. Вы знаете, что проект обречен. Вы знаете, что обещания руководства — пустой звук. Вы принимаете эти правила игры не из наивности, а потому что это текущая реальность, в которой нужно как-то функционировать.
Классификация неизбежного: В каком аду вы находитесь?
Йордан делит безнадежные проекты на четыре типа. Понимание того, где вы, определяет вашу стратегию поведения:
«Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.
«Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.
«Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.
«Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.
Принцип «Сортировки» (Triage)
Термин заимствован из военной медицины. Когда раненых слишком много, врач не спасает всех — он выбирает, на кого тратить ресурсы. В «Смертельном марше» происходит то же самое.
Вы понимаете, что 80% функционала, о котором мечтает заказчик, никогда не будет реализовано. Профессионализм здесь заключается в том, чтобы сосредоточиться на тех 20%, которые позволят системе выдать хоть какой-то результат в день релиза. Всё остальное — белый шум и декорации. Вы просто игнорируете второстепенные задачи, не тратя на них ни капли энергии, даже если менеджер бьется в истерике.
Эстетика процесса
Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».
Смертельный марш — это не про успех продукта. Это про вашу личную устойчивость в условиях тотального хаоса. Пока вы сохраняете дистанцию и понимаете, что это просто роль в плохой пьесе, вы остаетесь профессионалом.
P.S. Циатата:
Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.
Включая меня. Идиоты все, не только люди с низкими интеллектуальными показателями. Единственная разница между нами заключается в том, что мы идиоты по отношению к различным вещам в различное время. Неважно, насколько вы остроумны и находчивы, все равно большую часть дня вы проводите как идиот.
Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?
Условие
В IT-компанию N привезли экспериментальное устройство для автоматизации расчетов. Оно работает на урезанном интерпретаторе Python: никаких условий, сравнений или встроенных функций — только арифметика и битовые операции.
Знаки сравнения (>, < == и другие) использовать не получится, интерпретатор их не поймет и выдаст ошибку. Однако без них писать код довольно сложно. Придется реализовать базовую логику выбора большего из двух чисел.
Задача
Есть два числа: a и b. Найдите наибольшее из них, используя только сложение, вычитание, деление и умножение, а также битовые операции.
Нельзя использовать операторы сравнения (>, <, ==, != и т. д.), тернарный оператор, функции вроде max(), min() и прочее.
Попробуйте справиться с заданием. А один из вариантов решения показываем в Академии Selectel.
Спор о том, заберет ли ИИ работу у программистов, постепенно закрывается сам собой. Экспертизу и креативность человека заменить пока нельзя, но те, кто уже использует нейросети в работе, тратят меньше времени на рутину.
Но выбор инструмента — отдельная задача. GitHub Copilot, Claude, ChatGPT, DeepSeek, Tabnine — у каждого своя ниша, и кажется, что универсальной нейросети не существует.
Разобрали, чем они реально отличаются: кто лучше справляется с рефакторингом, кто — с архитектурными вопросами, а кто незаменим при работе с legacy. И не обошли стороной ограничения — галлюцинации, устаревшие знания и дыры в безопасности.
Приглашаем на доклад Deep Dive into JVM JDI: Capturing Live Execution for Automatic JUnit Test Generation
Привет! Если на выходных судьба занесёт вас в Новосибирский Академгородок, приходите на технический доклад с мемами от нашего коллеги Даниила Степанова на самой ламповой Java-конференции Сибири — SnowOne 2026 ❄️.
Deep Dive into JVM JDI: Capturing Live Execution for Automatic JUnit Test Generation
Глубокий технический разбор архитектуры инструмента, который использует Java Debug Interface (JDI) для захвата состояния работающей JVM и автоматического синтеза валидных unit-тестов.
Что будет в докладе:
Deep Dive в JDI. Подробный рассказ про JDI, преимущества и недостатки, а также как его использовать в нестандартных сценариях для безопасного захвата Heap и Stack Frame в реальном времени.
Реконструкция объектов. Reverse Engineering JVM-состояния для воссоздания сложных графов объектов.
Синтез Java-кода. Как превратить сырой дамп памяти в чистый, валидный JUnit-тест.
Роль LLM. Для решения каких проблем мы используем искусственный интеллект?
Доклад будет полезен Java-разработчикам, тем, кто интересуется внутренним устройством JVM, и всем, кто хочет автоматизировать написание тестов.
SSP SOFT — компания работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошлый год мы наняли 179 сотрудников.
Рабочие места предоставляются в московском офисе, который открылся в 2025 году у самой Красной площади. А еще есть вакансии в офис разработчиков в Томске и на удаленку из любой точки России.
Работа в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.
Что предоставляет экосистема SSP SOFT: ✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины. ✅ Центр компетенций и личное менторство ускорят развитие до максимума. ✅ Офис, гибрид или фулл-удаленка? Есть все варианты. ✅ Время — ваш ресурс. Мы его уважаем.
Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead Алине (https://t.me/AONikitina). Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».
Желаем всем хабровцам успешной карьеры в 2026 году 🚀
Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»
Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».
Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.
1. Программист — это не «печатающая машинка»
Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.
Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.
2. Эволюция «костылей»
Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.
ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструктычистого смысла
3. Проблема «идеального мусора»
ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.
4. ИТ-поликлиника
Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.
А кого вообще не заденет? (Спойлер: Работы будет завались)
Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.
Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог
Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.
ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.
Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.
Хорошей практикой в C++ считается размещение функций рядом с типами, для которых они предназначены. Однако, чтобы такой подход работал корректно, важно понимать механизмы поиска имён и знать, где можно размещать функции, не нарушая правил языка.
Совсем недавно мы проверяли проект OpenCV и нашли там довольно интересную ошибку. Рассмотрели её подробнее и написали новую статью специально для тех, кто хочет разобраться с механизмом поиска имён в C++, в частности с поиском имён по аргументам.
На Upwork появилась вакансия, которая отражает состояние индустрии ИИ-разработки: заказчик ищет вайбкодера, чтобы доделать приложение, которое не доделал предыдущий вайбкодер. Завершив уже больше половины работы, прежний исполнитель вдруг обнаружил, что у него больше «нет времени».
Вакансия гласит: «У нас есть незаконченный проект на GitHub, который был доведён при помощи вайбкодинга примерно до 75% готовности. У прошлого вайб-одера нет времени доделать его. Мы предоставим документацию и цели, чтобы вы могли использовать ИИ и свои навыки для завершения работы». Исполнителю предлагают создать персональный API-ключ, чтобы тот не тратил свой.
Вакансия понравилась пользователям Reddit. «Ищу несертифицированного хирурга, чтобы исправить неудачную операцию, выполненную предыдущим несертифицированным хирургом», — иронизирует один. «Ищу несертифицированного инженера-конструктора, чтобы починить дом, который рухнул из-за предыдущего вайб-инженера», — добавил другой. Кто-то отметил, что «75% готовности — это минус 20% готовности. Разгрести то месиво, которое уже накодили, займёт больше времени, чем написать всё с нуля». Кто-то напомнил принцип Парето, мол, оставшиеся 20% — на самом деле 80% работы.
Практический Тренажер по Java — самый популярный тренажер по Java на Stepik
В 2024 году я опубликовал курс «Практический Тренажер по Java» на платформе Stepik. Тогда это был просто практический курс с задачами — без воды, без длинной теории, только код и постоянная тренировка.
Прошло несколько лет.
Сегодня курс проходит более 19 000 учеников, и это самый популярный тренажёр по языку Java на платформе Stepik.
Курс продолжает активно развиваться, регулярно пополняется новыми задачами, а вокруг него сформировалось живое и активное сообщество.
И я хочу заново пригласить вас в этот проект.
Почему Java?
Java — один из самых востребованных языков программирования в мире.
Он используется в:
— веб-разработке
— мобильной разработке (Android)
— корпоративных системах
— финансовых сервисах
— высоконагруженных backend-проектах
Java — это стабильность, масштабируемость и высокий спрос на рынке труда.
Что представляет собой курс сегодня?
Это полностью практический формат обучения. Только задачи и реальная практика.
Многие ученики используют тренажер как системную подготовку к техническим интервью. Такой формат не просто помогает решать задачи, а выстраивает алгоритмическое мышление, формирует уверенность в собственном коде и укрепляет уверенность в своих силах и уровне владения Java.
Привет, Хабр. Делимся подборкой бесплатных уроков, которые скоро пройдут в Otus. Опытные практики проведут занятия онлайн — вы сможете узнать больше о формате обучения и задать вопросы экспертам. Выбирайте свою тему и присоединяйтесь.
10 марта 20:00. «Мультитенантная архитектура в Laravel: как масштабировать проекты под десятки и сотни клиентов». Записаться Открытый вебинар курса «Framework Laravel»
Задумывались ли вы, насколько высок современный налог на железо в разработке ПО?
У меня в руках настоящий «старичок» из 2002-го: сокет 478, матплата GA-8IR2003, Celeron 1700 МГц (по силам как Pentium III на 1 ГГц, но с поддержкой SSE2), 2 Гб ОЗУ, GeForce 4 MX и верный HDD на 40 Гб.
Я хочу написать о нем статью, но не в стиле ностальгический обзор ретро-игр такого в сети полно. Моя цель вдохнуть в него жизнь и проверить, пригоден ли этот 23-летний дедушка для современной разработки.
На борт успешно встают Windows 7 и Debian 11, что открывает доступ к актуальному софту, IDE и библиотекам. Хочется понять: реально ли на таком непотребстве поднять бэкенд на C# или собрать что-то серьезное на C++?
Запасной вариант, если основному ПК не хватит инструкций.
В запасе ПК: Athlon x4 640, 8гб ОЗУ, ssd 256.
На нем, отключая ядра и понижая частоту можно добиться симуляции ПК начиная с 2000-ого по 2010 год. Думаю этот вариант будет предпочтительнее. Но начну конечно с celeron'а.
Что планирую потестить:
C# под Linux: Запустить бэкенд и посмотреть, не «умрет» ли система.
Базы данных: Погонять PostgreSQL 9.4 (она еще дружит с 32-битными процессорами).
C++: Сравнить скорость сборки проекта с модулями и без них.
Безумный челлендж: Попробовать собрать userver. В чате разработчиков сказали "вряд ли взлетит", а мне тем более интересно проверить.
IDE: Какая версия Visual Studio оживет и можно ли в ней работать без боли.
Прошу совета у сообщества: накидайте идей! Какие бенчмарки прогнать? Какой софт или специфические проекты попробовать собрать, чтобы нащупать предел возможностей?
Будет интересно сделать вывод: пригоден ли древний ПК хоть для какой-то разработки сегодня, или «налог на железо» стал неподъемным. Жду ваши предложения!
OpenAPI Generator через призму статического анализатора
Знаете ли вы про OpenAPI Generator — open source проект, задача которого — автоматическая генерация клиентских библиотек, серверных заглушек, документации и файлов конфигурации на основе спецификации OpenAPI в формате JSON или YAML. Проект является достаточно популярным: у него чуть больше 25000 звёзд на GitHub.
Питер Штайнбергер пишет код не в Claude Code. Для многих это окажется неожиданностью, поскольку его проект OpenClaw был задуман в первую очередь как прокладка для общения с большими языковыми моделями компании Anthropic — в том числе в те периоды, когда этот самопис назывался warelay, Clawdbot или Moltbot. Тем не менее разработку Питер предпочитает вести в Codex компании OpenAI.
Прожорливый на токены и максимально небезопасный продукт привлёк внимания много и сразу. Энтузиасты по всему миру срочно ставят чат-бота на Mac mini и виртуальные серверы, чтобы потратить как можно больше токенов языковой модели Claude Opus. Зашла даже речь о продаже проекта. Как известно по интервью, Штайнбергер всерьёз рассматривает предложения приобрести OpenClaw и для этого выдвигает обязательное условие о сохранении открытости проекта. Утверждается, что наиболее интересные оферы поступили от Meta¹ и OpenAI, одних из самых крупных игроков в индустрии искусственного интеллекта.
Вообще, если следить за новостными лентами и его личным микроблогом, можно подумать, что Штайнбергер от дел отошёл, и просто бегает по интервью и встречам с фанатами. На самом деле разработка OpenClaw продолжается, новые версии выходят ежедневно, но и на подкасты про программирование время остаётся. (Ещё бы: Штайнбергер не пишет ни строчки кода, а просто промптит языковые модели — очень модный сейчас подход). К примеру, аккаунт OpenAI Developers обещает выпустить 23 февраля большое видеоинтервью с Питером, где тот расскажет про свой новый рабочий процесс с Codex. Пока что выложили просто небольшой тизер этого видеоролика.
Любопытно, что написал про это интервью сам Штайнбергер. Как он рассказывает, пришлось послать человека сбегать в магазин за новой футболкой — та, в которой австриец пришёл на съёмку, содержала логотип неназванной компании, и сотрудникам OpenAI подобное не понравилось. Штайнбергеру разве что дали выбор, в чём он будет на камере: либо в синей, либо серо-синей футболке.
Транснациональный холдинг Meta (1) — экстремисткая организация, его деятельность запрещена.
