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

В 2026 году каждый второй стартап обещает заменить команду разработчиков роем AI-агентов. Звучит как мечта уставшего тимлида: один агент пишет код, второй ревьюит, третий деплоит, четвертый отвечает на вопросы в Slack, а пятый, наверное, уже сам заказывает пиццу в офис. Никаких больничных, никаких «я не успеваю», только железная продуктивность 24/7.

Я тоже купился. Взял CrewAI, собрал команду из трёх агентов для анализа конкурентов и генерации отчётов. Демо отработало идеально: агенты обменялись парой сообщений, выдали связный Markdown-файл и даже отправили его в Telegram. «Ну всё, — подумал я, — теперь можно увольнять аналитиков и копирайтеров. Будущее наступило».

Ровно через четыре часа после запуска на реальной задаче я наблюдал картину, достойную сюрреалистического полотна: пять AI-агентов устроили бесконечный митинг в духе худших корпоративных созвонов. Они перебивали друг друга, уточняли уже уточнённое, ходили по кругу и, кажется, начали обсуждать погоду. Один агент назначил себя лидом и раздавал указания, которые остальные игнорировали. Другой пытался писать в файл, который в этот момент читал третий. Спустя 127 вызовов LLM и сожжённые $4.30 на API-ключах я остановил этот цирк вручную.

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

Три минуты на планирование, десять на исполнение. Да, в масштабах человека это быстро, но уже хочется еще быстрее!

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

Но платить за скорость — не единственный выход.

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

Эта — про деньги. Про то, сколько мне стоило не понимать, что у меня за паттерн. И про то, что я сделал, когда наконец понял.

Продолжаем серию «Kotlin для новичков». Сегодня разбираем фундамент, без которого не обходится ни одно приложение: строки и коллекции. Как правильно резать подстроки, форматировать JSON, чем List отличается от MutableList и зачем enum в Kotlin круче, чем в Java. Заглядывайте, будет полезно!

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

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

Давайте же разберёмся, какие костыли есть в телеграме и почему это не всегда плохо.

Гляньте-ка! Это я с сервером Minecraft, запущенным на компьютере UNIVAC 1219B:

А ниже будет эмулятор NES с первым отрендеренным кадром Pinball.

… и селфи, напечатанное на телетайпе при помощи техники многократной печати «overstrike».

Мы сделали ещё кучу безумных штук, и в том числе:

• Программы OCaml (!)

• Веб-сервер

• Шифрование Curve25519 + AES

• Интерпретатор BASIC

• ELIZA

• Игры наподобие Oregon Trail, Wordle и Battleship

… а также многое другое! И всё это на компьютере из 1960-х с частотой 250 кГц и всего с 90 КБ ОЗУ. Ради такого я и живу! Я одержим запуском кода в странных местах и преодолением технических ограничений. Этот проект стал для меня самым амбициозным на данный момент, он отнял у меня и других примерно восемь месяцев.

Исходники проекта я выложил на Github. Также можете посмотреть видео TheScienceElf об этом проекте!

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

Представьте сцену. Вы пишете в терминал: «разберись, почему на main падает вот этот тест, и попробуй починить». Жмёте Enter. Спиннер крутится, подписи меняются — сначала “Pondering…”, потом зачем-то “Julienning…”, потом “Recombobulating…”. Через минуту агент прочитал логи CI, нашёл зафейлившийся тест, заглянул в связанный модуль, заметил, что кто-то криво подкрутил регекс, предложил правку, дождался вашего «да» — и коммитит. Пока вы наливаете чай, PR уже уехал на ревью.

Выглядит как магия. На деле внутри — удивительно стройная инженерная конструкция: главный цикл на пару сотен строк, обросший целой экосистемой обслуживающих подсистем. Я несколько вечеров подряд ковырялся в исходниках одного такого CLI-агента для разработки: де-обфусцированный дистрибутив примерно на 300 модулей, файл-вход почти на 800 тысяч строк после разсборки бандла. И за «магией» обнаружились вещи, про которые отдельно хочется написать: собственный React-реконсилятор для терминала, двухуровневая загрузка описаний инструментов, классификатор опасных bash-команд, трёхрежимное сжатие контекста, fork-join для саб-агентов, защита от невидимых Unicode-инъекций в промпте.

Эта статья — мои заметки по итогам погружения. Не реклама конкретного продукта (реальных имён функций и классов я намеренно избегаю), а разговор про архитектурные решения, которые стоят за современным CLI-агентом. Главный цикл и его устройство, инструменты, контекст и его сжатие, разрешения и хуки, MCP, память между сессиями.

Когда AI-агент пишет код в пустом проекте, первые 30-40% токенов он тратит на ориентацию — читает README, туториалы, API-reference. Ни один формат не отвечает на главный его вопрос: “какой паттерн скопировать и где грабли?”

Вторая проблема глубже: LLM знает “всё на свете”, но распределено это неравномерно. Статей пятилетней давности в интернете больше, чем свежих — и агент по умолчанию тянет меня в прошлое, предлагая устаревшие рецепты. Каждый раз гонять deep research — дорого, и результат всё равно испаряется с сессией.

Happyin Knowledge Space — 785 статей в 26 доменах, под MIT. Reference cards, не туториалы. Граф wiki-ссылок вместо vector DB. llms.txt на шести языках. Пишется по результатам моих реальных ресерчей — каждый deep research теперь становится карточкой в базе и не испаряется. Локально разворачивается за 5 минут, работает без серверов и без embedding-моделей.

Telegraph API обещает принимать content до 64 КБ, но на практике CONTENT_TOO_BIG прилетает уже на 17-20 КБ. Разбираю, как измерял реальный лимит, при чём тут UTF-8 vs UTF-16 для кириллицы, и каким обходным путём чинил молчаливую деградацию RU-канала.

Представьте: сервис А звонит сервису Б, а тот зависает. Сервис А ждёт, занимает потоки, не освобождает ресурсы. Потом к нему приходит другой сервис — и тоже встаёт в очередь. Так один сбой разрастается по всей системе, как снежный ком. Этот эффект называется каскадным отказом.

Паттерн Circuit Breaker (предохранитель) решает эту проблему. В статье разбираем его на примере ассистента HR с зонтиком, показываем, как настроить Resilience4j, и делимся, какие ошибки стоит (а какие не стоит) учитывать в статистике.

 Описание

Паттерн Circuit Breaker (предохранитель) занимает важное место среди паттернов архитектуры приложений, особенно в микросервисных системах.

В чем его суть. Представим сервис А, который обращается к сервису Б. Сервис Б по каким-то причинам начинает плохо себя вести: долго отвечать на запросы или отвечать ошибкой — например, потерял соединение с базой данных. Тогда начинает «страдать» сервис А: он вынужден долго ждать на каждом запросе, занимая ресурсы — свободные потоки, соединения с БД, удерживая транзакции открытыми.

Проблема распространяется и умножается на всю систему. У сервиса А занимается всё больше потоков, которые ничего не делают, а просто ждут. Если будут заняты все потоки, сервис А станет полностью неработоспособен. Так проблема разрастается по цепочке — этот эффект называется каскадным отказом (cascading failure).

Чтобы решить проблему, сервис А должен иметь защитный механизм, который определяет, что сервис Б сейчас в аварийном состоянии, и временно не обращаться к нему. Этот механизм и называется Circuit Breaker (предохранитель).
 

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

<Картинка не влезла в превью.>

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

За остаток цикла мы должны выяснить, как можно строить среднеразмерные игровые сцены на F#, а также почему этот цикл называется так, как называется. Конкретно в этой главе мы разберёмся с RenderingServer-ом (бывший VisualServer), но не с нуля, а с позиций достигнутых в »Godot — рисование без правил» и »Прямоугольные тайловые миры». Если вы уже прочитали эти статьи, то вам должно быть известно, что рисование через RenderingServer — это довольно экзотический подход, который воспринимает хождение сквозь стены как рядовое событие. Авторы движка этому не препятствуют, но и не содействуют, поэтому документации по этому серверу — кот наплакал. Мне так и не удалось выудить ответы на все интересующие меня вопросы в словесной форме и их пришлось выковыривать при помощи живых экспериментов. Последние ни в статью, ни в проект не влезли, но тут важна сама парадигма, при которой мы всегда отталкиваемся от практики, а не от теории, которой пока просто нет.

Описание модели памяти Go начинается со слов «если вы читаете этот документ — вы излишне умный, остановитесь». Многие и правда остановились, но не автор этой статьи. 

Привет, Хабр! Я — Игорь Панасюк, и это вторая часть материала по мотивам моего выступления на GolangConf, где я рассказывал о модели памяти Go. В первой мы разобрались с  отношением happens before, формализмом, посмотрели практические примеры и многое другое. Сегодня поговорим о линеаризуемости исполнения, барьерах памяти (можно ли опустить абстракцию модели памяти), гарантии для программ с data race и использовании продвинутых техник.

В 47 мои увлечения стали Си, Radare2 , Биты, Логика, Память. Изучая память зацепился за адреса. На адрес 0x7ffe10b284 можно смотреть бесконечно долго. Трудно сказать с ходу насколько удачно ваши данные легли в память. Влезают они в одну кеш-линию или размазаны по двум. Чтоб не заниматься битовой арифметикой в уме, я написал утилиту на Си для Linux и Termux. Она раскладывает младшие 12 бит адреса на 4 строки визуализации. Теперь сразу видно, попали мы в "Голову" или застряли в "Хвосте" кеш-линии.

Утилита максимально легковесная. Вам не нужны сложные дебаггеры, достаточно gcc. Работает, как на десктопном Linux, так и в Termux на Android. Можно проверить выравнивание даже лёжа на диване.

4-я статья из цикла туториалов о вариантах кастомизации своего бизнес-портала в Битрикс24.

Сегодня рассказываем о работе с уже существующим проектом через AI-агентов. ИИ хорошо справляется с созданием новых приложений, но при работе с готовыми проектами чаще возникают сложности — например, при разборе архитектуры и внесении изменений без поломок

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

Я взглянул на апрельский рейтинг TIOBE за 2026 год и протёр глаза. Python, C, C++, Java, C# — скучно. Но вот на 10-й строчке восседает Delphi. А Fortran, язык, на котором писали ещё при царе Горохе и который, по мнению всей «модной» тусовки, давно должен лежать на свалке истории, стабильно держится в топ-15. В марте 2025 года он вообще ворвался в двадцатку вместе с такими «мамонтами», как Ada и COBOL.

Что за чертовщина? Rust, который кричали на каждом углу как «убийцу С++», пыжится на 16-м месте, а его рост, по словам генерального директора TIOBE Пола Янсена, замедляется. В это же время Fortran, тихо и без лишнего шума, продолжает быть фундаментом, на котором держится вся мировая наука. Почему компании не переписывают миллионы строк легаси на Python или Go? Потому что цена ошибки в коде, который считает ядерный реактор или прогноз погоды на завтра, исчисляется не в часах разработчика, а в миллиардах долларов и человеческих жизнях.

Давайте разбираться, что такое современный Fortran и почему ваш скепсис по поводу «динозавра» не имеет под собой никаких оснований.

Книга iOS 18 App Development Essentials (русское издание — «Основы разработки приложений для iOS») относится к тому типу учебников, которые остаются полезными даже при смене версий платформы. Основание так утверждать состоит в том, что автор выстраивает материал вокруг полного цикла разработки приложения, т.е. от установки набора средств разработки (SDK, Software Development Kit) и настройки среды до публикации в магазине приложений App Store. Такой подход делает книгу не просто справочником по версии iOS 18, а последовательным курсом по созданию приложений для операционной системы iOS в целом.

Привет! На связи Антон Полухин из Техплатформы Городских сервисов Яндекса. После большого релиза 🐙 userver прошло почти два года. За это время мы обзавелись большим количеством внешних пользователей — международных и российских. При этом и количество внутренних пользователей подросло: в Городских сервисах Яндекса появились стни новых сервисов на userver. Функциональность Такси, Еды, Лавки, Доставки, а также Маркета, Финтеха, Фантеха, Электро и Техплатформы обогатилась новыми возможностями и новыми пользователями. А значит, фреймворк стал ещё надёжнее и оттестированнее.

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

18 ноября 2025 меня уволили с позиции ведущего фронтенд‑разработчика. В руках — свежеоформленная IT‑ипотека, в календаре — 6 месяцев, чтобы найти новую аккредитованную компанию, пока льготная ставка не превратилась в рыночную.

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

В этой статье я рассказываю, как прошел путь от самоуверенного «да я за неделю найду» до стадии «может, пойти в курьеры?». Делюсь выводами о том, как сейчас работают (или не работают) отклики, и почему нетворкинг в итоге спас мой семейный бюджет.