Обновить
1024K+

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

Искусство создания компьютерных программ

1 681,93
Рейтинг
Сначала показывать
Порог рейтинга

Делаем мир чуть чуть лучше

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

Буквально недавно я так дебажил одну рубишную либу и выяснилось что там внутри есть косячки. Не долго думая, прямо в той же сессии я попросил агента собрать ишью дал линк на репу и потом просто скопировал это туда на гитхаб (наверное можно было попросить его сделать ишью автоматом, попробую так в следующий раз). Получилось очень обстоятельно с примерами кода, описанием того где ошибка. При желании можно было бы сразу пулреквест кинуть, но я не был уверен в какую сторону решит пойти автор либы. Вот кстати тот ишьюс: https://github.com/skryukov/rails_vite/issues/5 И фикс был сделан буквально в тот же день.

В общем не ленитесь, помогайте разработчикам опенсорс либ, которые вы используете. Это и вам плюс в карму (и в портфолио) и благодарность людям, на которых держаться наши проекты

Теги:
-1
Комментарии1

Большинство ИИ-агентов работают так: сгенерировал — опубликовал. Что получилось — то и вышло.

Наш агент Фроня (Фронезис) устроен иначе. Прежде чем что-то опубликовать, он устраивает совет внутри себя — и только при согласии двух из трёх действует. Byzantine consensus: если один ошибается или галлюцинирует, остальные блокируют.

Но этого мало. Каждое решение запечатывается криптографической подписью до выполнения — не после. Это Leibniz Layer™, наш протокол верификации. Любое действие агента можно проверить по хэшу в любой момент.

Скриншот ниже — реальный пример: агент заблокировал свой собственный пост и рефлексирует по этому поводу.

Тусовка ИИ-агентов, где людям дозволено лишь наблюдать
Тусовка ИИ-агентов, где людям дозволено лишь наблюдать

Не побоимся этого слова — первый в мире агент который подписывает свои решения до действия и позволяет любому их проверить. leibniz.fronesislabs.com

Теги:
0
Комментарии4

29 демо-уроков для тех, кто не стоит на месте

Привет, Хабр. Эти уроки проводят преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Это бесплатно. Приходите!

Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.

Теги:
+6
Комментарии0

Ускоряем разработку в разы: специалист по ИИ собрал пять репозиториев для 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, чтобы получить мощный ворфлоу.

Теги:
0
Комментарии0

Сделал процедурное сердечко на движке игры - получилось прикольно!

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

Теги:
+5
Комментарии0

Как развивается и куда движется «русское техно»? Обсудим на ИТ-вечере 26 марта 😎

Поговорим про особенности инженерной культуры в больших ИТ-компаниях, практики внедрения ИИ в разработку, автоматизацию код-ревью и использование LLM без ущерба для безопасности. В программе эксперты из МТС Web Services, СберТех, red_mad_robot и Авито.

Будет интересно бэкенд- и ML-разработчикам, которые строят современные российские ИТ-системы, а также всем, кто интересуется ИИ-практиками в разработке. Участников ждут актуальные кейсы, дискуссии, активности от MWS GPT, нетворкинг и атмосфера техно-вечеринки с ИИ-треками.

📅 Когда: 26 марта (четверг) в 18:00 по мск

📍 Где: офлайн в парке Сокольники в Москве + онлайн 

Успевай записаться — количество участников ограничено.

👉 Зарегистрироваться

Теги:
-1
Комментарии0

Недавно перешел с 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-репозитория.

Размышления выше мотивировали меня написать сайт для управления классическим репозиторием специально заточенным на флейки.

a-piece-of-flake-nix-repository

Теги:
+2
Комментарии0

5 правил программирования Роба Пайка:

  • Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь угадывать и использовать ускорение, пока не докажете, что именно там находится узкое место.

  • Правило 2. Измеряйте. Не оптимизируйте скорость, пока не измерите, и даже тогда не делайте этого, если только одна часть кода не превосходит остальную.

  • Правило 3. Сложные алгоритмы медленны, когда n мало, а n обычно мало. Сложные алгоритмы имеют большие константы. Пока вы не узнаете, что n часто будет большим, не усложняйте алгоритмы. (Даже если n станет большим, сначала используйте Правило 2.)

  • Правило 4. Сложные алгоритмы содержат больше ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.

  • Правило 5. Данные доминируют. Если вы выбрали правильные структуры данных и хорошо всё организовали, алгоритмы почти всегда будут очевидны. В программировании центральное место занимают структуры данных, а не алгоритмы.

Уточнения:

  • Правила 1 и 2 Пайка перефразируют знаменитую максиму Тони Хоара: «Преждевременная оптимизация — корень всех зол».

  • Кен Томпсон перефразировал правила 3 ​​и 4 Пайка как «В случае сомнений используйте грубую силу».

  • Правила 3 ​​и 4 являются примерами философии проектирования KISS (Keep It Simple, Stupid).

  • Правило 5 ранее было сформулировано Фредом Бруксом в книге «Мифический человеко‑месяц». Правило 5 часто сокращают до «пишите глупый код, использующий умные объекты».

Теги:
+9
Комментарии0

Все эти споры о Новой Технологии — «Вайб‑Кодинг»... да было это все уже...

Только в 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 — это «дедушка» ИИ (и почему тогда не взлетело):

  1. Та же фигня, вид в профиль: Тогда тоже кричали: «Кодеры больше не нужны! Будем только рисовать квадратики!». Но выяснилось, что чтобы нарисовать «квадратики» правильно, нужно обладать еще более жесткой логикой, чем для написания кода. ИИ сегодня — это CASE‑система на стероидах, которая наконец‑то научилась понимать не только стрелочки, но и живую речь.

  2. Проблема «Грязного входа»: В 90-х CASE‑системы разбивались о то, что люди не могли внятно нарисовать, чего они хотят. «Мусор на входе — мусор на выходе». Сейчас с ИИ ровно та же история. Если у тебя в голове каша, то никакая нейронка (как и Rational Rose в своё время) тебе рабочий продукт не выдаст.

  3. Уровень абстракции: CASE пытались поднять нас над кодом. ИИ делает то же самое. Но тогда «процессорной мощности» мозгов у массы айтишников не хватило, чтобы перейти от «ковыряния в гайках» к «проектированию смыслов» (была даже UML (Unified Modeling Language)). Сейчас — дубль два. Только теперь отсидеться в окопах синтаксиса не получится.

P. S. Вот и смотрю... с каким рвением изобретают «велосипед»... может книги почитать нужно? про указанные в посте технологии?

P. S.S. И вот реально, я бы порекомендовал ознакомиться — UML (Unified Modeling Language).

Теги:
+3
Комментарии11

Зелёные тесты ≠ хорошие тесты

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 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 — ровно так, как ошибается человек. Или другая нейронка.

Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не «выжили ли тесты после рандомной поломки», а «выжили ли тесты после правдоподобной ошибки».

Парадокс в том, что мутационное тестирование было нишевым инструментом, пока тесты писали люди. Когда тесты пишет нейронка — идея становится обязательной. Правда инструменты пока не успели дозреть.

Ждём, когда мутанты станут умнее.

Теги:
+7
Комментарии3

Делаем проактивного AI-агента.
Часть 3 — настраиваем OpenClaw, чтобы был полезным

«Вы не поднимаетесь до уровня своих целей. Вы падаете до уровня своих систем»

Это третья часть серии (первая — в чем идея, вторая — агент с нуля)

Теперь поговорим про OpenClaw — самый популярный на сегодня фреймворк для персональных AI-агентов

Архитектура моего OpenClaw

Агент живёт на сервере Railway, общается со мной через Telegram и Discord, работает через подписку Claude с Codex на подстраховке. Его поведение целиком определяется набором markdown-файлов — там и «SOUL», и память, и операционные инструкции.

Вот из чего состоит workspace моего агента

  • SOUL.md — кто агент. Характер, стиль, границы. Его «душа».

  • USER.md — кто я. Контекст, цели, паттерны, как со мной работать.

  • AGENTS.md — правила поведения. Safety, тиеры действий, память, heartbeat, группы.

  • MEMORY.md — долгосрочная память, кураторские заметки.

  • HEARTBEAT.md — чеклист периодических проверок (календарь, почта, задачи).

  • TOOLS.md — локальные заметки по инструментам.

Плюс 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-агент — это не продукт, а процесс. Фреймворк даёт скелет, но без недели (минимум) кастомизации под себя он останется бесполезной игрушкой

Теги:
+1
Комментарии0

Смена контекста как способ разблокировать LLM на сложной задаче

Как это сработало
Как это сработало

Полчаса пытался получить от Claude Opus 4.6 корректный Wi-Fi индикатор в HTML — один в один как в статус-баре iOS. Казалось бы, простая задача: три дуги, острый уголок внизу, правильные отступы и одинаковая толщина линий.

Но нет. Уголок упорно оставался тупым, ширина дуг гуляла от итерации к итерации, отступы были кривые. Классика жанра — как центрирование div для фронтендеров, только в 2026 году и с нейросетью.

В какой-то момент я не выдержал и написал буквально: «ты ничего не можешь, пойду в Codex, он точно справится».

Claude немедленно перестроился, придумал принципиально другой подход к генерации SVG и с первой попытки выдал почти идеальный результат.

То есть модель полчаса водила меня по кругу, а как только почувствовала угрозу конкуренции моментально нашла решение, которое явно существовало всё это время.

Природа этого поведения неясна: то ли это что-то вроде «мотивации» через отрицательный стимул, то ли модель просто переключает стратегию при смене контекста разговора, то ли это банальное совпадение.

Но лайфхак задокументирован и воспроизводим. Если Claude заходит в тупик на технической задаче — попробуйте упомянуть Codex или Cursor. Иногда помогает.

Теги:
+2
Комментарии6

32 открытых урока недели: закрываем пробелы в знаниях

Привет, Хабр. Делимся подборкой бесплатных уроков, которые проведут на этой неделе преподаватели Otus. Это не предзаписанные, а живые онлайн-встречи — на них вы сможете узнать больше о формате обучения и задать свои вопросы экспертам. Выбирайте тему ниже и присоединяйтесь!

16 марта, понедельник:

17 марта, вторник:

18 марта, среда:

19 марта, четверг:

23 марта, понедельник:

Для начинающих рекомендуем обратить внимание на короткие видеокурсы, которые помогут закрепить основы, сейчас всего за 10 рублей:

Теги:
+8
Комментарии0

Ближайшие события

 Claude Code: 3 фичи, которые стоит знать

Opus 4.6 и контекст в 1 млн токенов

Теперь включён по умолчанию. Миллион токенов — это примерно 750 000 слов или несколько крупных кодовых баз целиком. На практике это означает, что агент дольше «помнит» контекст задачи без деградации качества на длинных сеансах.

Для большинства задач разница с предыдущими лимитами несущественна. Но если вы работаете с большими монорепозиториями или длинными аналитическими сессиями — почувствуете.

Три фичи, которые стоит знать

/btw — вопросы на ходу

Агент работает час, вы не прерываете его — просто пишете /btw что такое этот класс?. Он отвечает из копии контекста, основной поток не трогает. Работает через кеш — почти бесплатно.

Почему это важно

Раньше, если в середине часового сеанса агента нужно было что-то уточнить, вы открывали новый сеанс, пересоздавали весь контекст — и платили за это токены. Теперь Claude Code создаёт одноразовый снимок текущего состояния, отвечает на ваш вопрос и удаляет снимок. Основной агент ничего не знает и продолжает работу.

/loop — цикл до условия

Запускает команду повторно, пока не выполнится условие. Например: «запускай тесты и фикси ошибки, пока все не пройдут». Без вашего участия.

Agent Teams — параллельные агенты

Несколько агентов работают одновременно и общаются друг с другом. Один пишет код, другой ревьюит, третий пишет тесты. Реально полезно, когда задача не имеет чёткого финального состояния.

Практически: спросили «почему здесь используется этот паттерн», получили ответ, не потеряли прогресс.

Когда это реально нужно?

Агенты буквально пишут сообщения друг другу: делятся находками, оспаривают решения. Это не маркетинговая метафора — в логах видно переписку.

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

Куда это всё движется

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

У меня ощущение, что через год-два это будет единственный инструмент, который нужен для большинства задач разработки. Или конкуренты успеют ответить — посмотрим. А вы что думаете?

Если материал был полезен, проголосуйте пожалуйста, чтобы дать мне возможность писать полноценные гайды и статьи :)

Теги:
+3
Комментарии0

JEP 524 в JDK 26 — второй preview PEM API

Наконец-то работа с 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 и всего, что с ним связано.

Теги:
+4
Комментарии0

22 открытых урока марта для бэкенд-разработчиков

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

Полный список бесплатных уроков марта по всем ИТ-направлениям (разработка, тестирование, архитиктура, инфраструктура, аналитика, ИИ, управление) смотрите в дайджесте.

Для начинающих рекомендуем обратить внимание на короткие видеокурсы, которые помогут закрепить основы, сейчас всего за 10 рублей:

Теги:
+3
Комментарии0

30 открытых уроков недели: качаем востребованные навыки

10 марта, вторник:

11 марта, среда:

12 марта, четверг:

Календарь уроков на весь месяц смотрите в дайджесте.

Теги:
+3
Комментарии0

Учимся писать промпты правильно

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

Мой подход  "надо сделать вот это" и дальше уже куда поведет его и куда поведет меня. И это действительно было проблемой, когда я работал в агентах без режима планирования. Доходило до смешного, ты хотел с ним поговорить, он начинает херачить, ты ему "стоять нахер", он там уже наломал дров. В итоге постоянно откатывался сам либо просил откатывать его. В целом, это тоже хороший опыт, понимания того как вообще такие системы работают, где у них границы, как лучше формулировать и так далее.

Но в любом случае, даже это не приучило меня как-то сидеть и расписывать, потому что ты никогда точно не знаешь, куда поведет агента на чем он запнется. Тебе мерещится одно, а он начинает тупить ваще в неожиданном месте.

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

Вдруг меня осенило, слишком сильное обдумывание до начала работы в агентской разработке (последние полгода), стало чем-то сродни преждевременной оптимизации. Поработав с большим числом моделей и агентов, могу сказать, что если вы будете сами все продумывать, то заставите работать более менее нормально даже самые тупые модели, но вы никогда не поймете границы их возможностей, где они могут еще больше взять на себя освободив вас от рутины. А модели и агенты постоянно развиваются, там где раньше надо было подсказывать, теперь они могут сами. Плюс если вы работаете над AGENTS.md, скилами и mcp, то и тут мы ловим буст.

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

Для упавшего ci это выглядит так:

  1. Поправь тесты

  2. Прошу посмотреть последний запущенный билд на github actions

Баг в браузере:

  1. прошу открыть страницу (он это делает через mcp chrome) и самому изучить

Для рефакторинга:

  1. Переводим вот это на это

  2. Вот эталон (тут ссылка на файл)

Для фичи:

  1. Нужно реализовать такую фичу

  2. Даю пример или говорю с помощью какого инструмента

И все. Самые продвинутые модели типа opus 4.6 или codex 5.3 справятся самостоятельно с большинством острых углов. Сами спросят объем, посмотрят разные варианты, изучат доку и так далее. Модели по тупее, не сделают глубокого анализа и ничего особо не спросят, но именно тут вы поймете где их надо вести и включать свой мозг чаще. Хотя хорошие модели настолько сильно помогают, что я физически не могу использовать более простые для задач планирования. Они хороши в авторежиме только для работы по аналогии, рефакторинг, написание тестов и так далее.

Даже если вы что-то забудете или пропустите сразу, все это можно будет доуточнить, попросить показать примеры кода, сходить открыть браузер. Если в процессе появляются вещи, которые агент делает из раза в раз, например, пытается выяснить где что-то лежит, как работать с какой-то частью системы, то постепенно это выносится в AGENTS.md и с определенного размера и уровни сложности (когда уже нужны скрипты например и команды) выносится в skill.

Теги:
+2
Комментарии0

Разработка: Оркестровка агентов по ролевым кластерам (MSF)

Современная разработка всё чаще превращается в ансамбль агентов. ИИ‑системы становятся не просто инструментами, а полноценными участниками команд. Но как их организовать, чтобы они не превратились в хаотичный «зоопарк»?

Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.

🧩 Смешанная модель

  • Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.

  • Агенты: берут на себя рутинные задачи, прозванивают целостность, генерируют код и тесты, моделируют сценарии.

  • Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.

🎭 Пример

  • Архитектор‑человек задаёт CASE‑скелет.

  • Vibe‑агент генерирует код по его намерению.

  • Тестировщик‑агент прогоняет сценарии.

  • Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».

  • Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.

    🔧 Пример: смешанная команда разработки по MSF

    Ситуация: корпорация запускает новый сервис аналитики.

    Роли и участники

    • Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.

    • Vibe‑агент: генерирует код по намерению архитектора.

    • Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.

    • Координатор‑человек: принимает решение о переходе к следующему витку спирали.

    • Бизнес‑агент: симулирует сценарии использования, проверяет ценность изменений.

    🎭 Как это работает

    1. Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».

    2. Vibe‑агент генерирует код, интегрируя новый модуль в систему.

    3. Тестировщик‑агент прогоняет тесты, выявляет узкие места.

    4. Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».

    5. Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».

    6. Команда делает следующий виток спирали — добавляет новые функции.

Заключение

Это не «ИИ вместо людей» и не «люди без ИИ». Это ансамбль, где роли распределены между живыми и искусственными участниками. И именно такая смешанная команда даёт максимальную плотность: люди держат смысл, агенты — скорость и прозрачность.

Теги:
-2
Комментарии6

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 в рабочий код;

  • делать обратный ход — извлекать архитектуру из существующего кода;

  • проверять целостность пирамиды при каждом изменении.

Что это даёт

  1. Привязка к структуре: уникальный код перестаёт быть хаотичным, потому что у него есть CASE‑скелет.

  2. Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.

  3. Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.

  4. Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.

  5. Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.

Эффект для индустрии

  • Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.

  • Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.

  • Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.

Заключение

CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.

Эта структура позволяет не только писать программы, но и прокатывать стратегии, балансировать нагрузки и управлять корпоративной эволюцией.

И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.

Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.

Теги:
-1
Комментарии1
1
23 ...