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

Если вы пишете код, или так или иначе задействованы в разработке ПО, или просто следите за тем, как ИИ меняет разработку, то наверняка слышали тревожный тезис: «Скоро ИИ будет писать код лучше людей, и разработчики станут не нужны». На интуитивном уровне кажется, что если машина делает ту же работу в 8 раз быстрее, то бизнесу нужно в 8 раз меньше людей. Но экономика и история индустрии говорят об обратном — и тут очень кстати оказывается старый экономический парадокс, которому уже больше 150 лет.

Меня зовут Юлия Аравина, я карьерный стратег и коуч IT-руководителей, а также ведущая кейс-клубов на курсе «Технический директор — СТО» в Яндекс Практикуме PRO. В своей практике я замечаю одну закономерность: многие кризисы после повышения выглядят одинаково.

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

Многие объясняют это нехваткой навыков: кажется, что нужно лучше делегировать, увереннее принимать решения или пройти ещё один курс по менеджменту. Но чаще всего проблема глубже. После повышения человеку приходится перестраивать не только набор навыков, ему приходится заново отвечать на вопрос: «За что я вообще себя уважаю?» 

Давайте разбираться.

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

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

Идея простая:

1. Пользователь обводит объект лассо.
2. Нажимает кнопку Select object with AI.
3. Плагин локально строит мягкую alpha-маску.
4. Krita получает обычное выделение, с которым дальше можно работать штатными
   инструментами.

Назвать плагин я решил Krita Smart Select.

Репозиторий:
https://github.com/BMFreed/krita-smart-select

Релизы:
https://github.com/BMFreed/krita-smart-select/releases

У меня был ранний доступ к первой публично доступной модели класса Mythos — Claude 5 Fable. Большинство обсуждений вокруг Mythos сосредоточено на кибербезопасности, но я тестировал модель на всём остальном (ограничения Fable фактически блокируют её использование в этой области).

Мой вывод: это реальный скачок относительно всех моделей, с которыми я работал раньше. И, что важнее, он говорит о фундаментальных изменениях в том, как мы взаимодействуем с AI.

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

Звали его сэр Чарльз Энтони Ричард Хоар. Для друзей — Тони. Для пары поколений студентов — C. A. R. Hoare, тот самый, что в 26 лет придумал quicksort, выиграв у начальника спор на шесть пенсов. Тьюринговская премия 1980 года, логика Хоара, CSP, на которой потом выросла половина теории конкурентности. Большая, красивая, почти безупречная карьера.

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

Это null.

Есть расхожий сюжет: коварная индустрия наплодила багов, а гениальные инженеры героически с ними борются. Красиво. И, как обычно, неправда. Потому что самый дорогой баг в истории софта добавил не злодей и не нерадивый джун. Его добавил один из умнейших людей в истории computer science. 

Вот про эту историю и поговорим.

Каждый раз, когда техно-энтузиасты на Хабре начинают петь оды ИИ, который вот-вот заменит всех разработчиков, меня охватывает легкий скепсис. Дело в том, что многие простые задачи совсем не так просты, как кажутся нейросетям или продакту. Знаменитое: “да что там делать, вон ИИ отдай, к вечеру уже на прод зальете”, обычно открывает такую кроличью нору, что проваливаться и падать там можно неделями, а приземление оказывается очень болезненным. 

Вот казалось бы, что сложного, сделать дверь в игре? В 2014 году у Liz England вышло отличное эссе “Проблема Двери”, где Лиза описывает 22 логических вопроса, на которые должен ответить гейм-дизайнер при установке двери в игре. Эссе стало настолько классическим, что в сабредите r/GameDesign автомод прикрепляет ссылку на него в каждый тред. При этом эссе явно выходит за границы геймдева и становится универсальным, показывая, что кажущаяся простота в нашем деле часто не является таковой. Это касается и дверей в игре, и “просто логина на сайте”, и задачи вызова лифта, и визуализации прогресса ожидания и ещё тысячи вещей, необходимость детального продумывания которых менеджментом обычно в расчет не берется.

Я сделал это! Это огромный повод для гордости. Теперь программа работает по тем же математическим принципам, что и самые передовым фрактальным в мире!

Ключевые особенности:

Расчёт опорной траектории на 5000 бит всего один раз.
Реактивный расчёт миллионов пикселей на аппаратном double.
Революционный алгоритм Reference Reset to Zero.
Настоящий SSAA 8x8 для идеально сглаженного изображения без алиасинга.
Параллелизм OpenMP для высокоскоростного многопоточного рендеринга.

Есть полный код в С++ - main.cpp
Есть Гитхаб https://github.com/Divetoxx/Mandelbrot#russian с версии в виндовс Mandelbrot_windows_msse3.exe и Mandelbrot_windows_mavx2 и для Линукс Mandelbrot_linux_msse3 -msse3 и Mandelbrot_linux_mavx2

Всем привет! Продолжаю тему локальных LLM. В предыдущей статье мы сравнивали железо для инференса — Nvidia DGX Spark, Mac Studio M3 Ultra и Strix Halo. И как можно было догадаться, я остановился именно на последнем.

Теперь, когда железка есть, встает вопрос: а как из неё извлечь практическую пользу?

Claude code с оригинальными LLM - это, конечно, замечательно. Но это стоят денег, да и свой код в чужие дата-центры не всегда правильно лить. Плюс за всякое неосторожное движение можно попасть в бан, рискуя потерять все свои наработки.

Одно из решений: Claude Code во free mode с локальными моделями. Anthropic позволяет заменить свои модели на любые с совместимым API. То есть, на что угодно — даже на модель, крутящуюся прямо у вас на компьютере.

В этой статье я расскажу, как всё это настроить на Strix Halo — от загрузки моделей до первого запроса к Claude Code.

В стандарте C++20 было представлено множество нововведений, и одним из наиболее крупных и долгожданных в их числе являлись модули. Теперь, когда с тех пор минуло около шести лет, то воодушевление сменилось здоровым цинизмом. Так, авторы сайта Are We Modules Yet прогнозируют, что поддержка модулей во всех библиотеках будет обеспечена к 1 мая 2167 года, а на Reddit не проходит и двух недель, как возникает очередной тред на тему: «Ну что, ими уже можно пользоваться»? (спойлер: нет).

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

Многие ML‑инженеры знают, что нужно использовать CrossEntropyLoss, log_softmax и logsumexp. Гораздо меньше людей могут объяснить, что именно они спасают и почему без них обучение модели периодически превращается в генератор nan. Именно об этом и поговорим.

В августе 2025 года TypeScript впервые возглавил рейтинг GitHub по числу активных контрибьюторов, обойдя Python и JavaScript. Изменился подход к написанию кода: типы стали машиночитаемыми контрактами, фреймворки сделали TS вариантом по умолчанию, а ИИ-инструменты используют типы как ограничения. Разбираемся, какие цифры подтверждают тренд, где он создаёт издержки и как выбирать стек в 2026 году с учётом изменений рынка.

Тема конечных автоматов (КА) актуальна. Почти как тема реализации светофоров. Но вот, если серьезно, только отношение к ней разное. Время от времени появляются статьи типа «Конечные автоматы (FSM) – это ловушка для программиста» [1]. И здесь очень не хочется, чтобы складывалось превратное представление о некой «псевдо-математической» автоматной абстракции. Нужно оберегать народ от подобных суждений, которые ни на чем не основываются.

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

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

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

Наткнулся на репозиторий claude-code-best-practice — под 56 тысяч звёзд, #1 в GitHub Trending, внутри собраны в том числе советы самого создателя Claude Code. И поймал странное чувство: весь последний год я по кусочкам писал статьи ровно про то, что тут лежит в одном месте. Оркестрация, индексация кода, память агентов, выбор модели — это всё узлы одной карты. Но в одном месте карта спорит с моим опытом. Репо жёстко заявляет: «agentic search (glob+grep) бьёт RAG, векторные БД мы попробовали и выкинули». А я прямо сейчас внедряю Graphify во все проекты — и он работает: быстро, точно, сокращает токены. Кто из нас прав? Полез разбираться — и нашёл, что сам создатель Claude Code признал: ранний Claude Code использовал RAG, но agentic search «обогнал всё, и это было неожиданно». Правда, добавил: «оценивали в основном по ощущениям». В статье распутываю этот спор и выкладываю навигатор по репозиторию на русском.

Всем привет! Я молодой java-лид в одной из "гостех" контор и меня мучает вопрос, или навязчивая мысль "А что мы получим, делегировав разработку ИИ"...

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

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

Во-вторых, разве нам, кто пишет код, так интересно становиться "операторами IDE"? Это же насколько унылой стала работа: пишешь промт, ждешь n секунд/минут, получаешь какое-то решение, ревьюишь его, а кто-то и ревьюит агентами, коммитишь, а кто-то и это делает агентами. Все..? Это же не инженерия, а очень вялый cuк-OLD-инг :)

Первичное наполнение контекста — крайне важная задача, результаты которой влияют на качество решения/сгенерированного кода, возможно, даже больше, чем выбранная модель. В Claude Code за это отвечает Explore sub-agent, который, к слову, справляется неплохо, ровно до тех пор, пока вы не начинаете "по настоящему" использовать Spring: добавляя собственные starters, используя OpenAPI (Spec-first), определяя Bean/Components в стиле Josh Long (описывая их в конфигурациях), а также внедряя множество других инструментов фреймворка. В этом случае качественный анализ можно провести, только зная особенности работы Spring Framework и экосистемы.

В этом выпуске еженедельного дайджеста Skill of the week разберёмся, как, используя Spring Explore Skill, научить агента понимать специфику Spring-приложения и выполнять качественный первичный анализ.

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

Поэтому я считаю важным данной статьёй провести небольшой экскурс в мир нестрашной математики на примере самых востребованных распределений имитационного моделирования. Зная их и немного статистики, уже можно называть себя неплохим «модельером». Так давайте сделаем ещё один шаг к этому званию.

Качество работы с кодящим агентом почти не зависит от того, какая под капотом модель. Я довольно долго в это не верил — менял модели, крутил промпты, ждал следующий релиз. А разница, оказалось, не в модели. Она в том, что вокруг модели: есть ли у агента память между сессиями, карта проекта, правила, руки и место под результат. Голая модель — это эрудит без рабочего места. Каждый разговор она начинает с чистого листа.

Вот это всё вокруг модели — память, карта, правила, руки — и называется харнесс. Ниже — разбор моего харнесса целиком, слой за слоем, на одном реальном проекте: пять сервисов, Kubernetes, прод. Не идеальная схема из README, а то, что видно в логах: что реально вызывается каждый день, а что я нагородил и забыл. Спойлер: половина подключённых MCP-серверов за 98 сессий не вызвалась ни разу. Сразу оговорюсь: сессии сохранились не все — у Claude Code, похоже, есть ротация логов, часть истории потерялась. Так что мои числа — это нижняя граница, реальные ещё выше.

Открываешь чужой код на Python, а там — Java. Абстрактные базовые классы в местах, где хватило бы простой функции, фабрики фабрик и нагромождение паттернов, усложняющих чтение бизнес-логики. Знакомая картина?

Многие разработчики механически переносят архитектурные привычки из строго типизированных языков в Python, создавая переусложненный неидиоматичный код. В этой статье мы возьмем классические правила SOLID и переведем их на язык динамической типизации (Pythonic way). Разберем на реальных примерах, где принципы спасают проект, а где слепое следование им скатывается в карго-культ.

Я наткнулся на подход к функциональным тестам, который меня по-настоящему удивил. Тесты в нём вообще не знают, что внутри Spring: стучатся в реально поднятый сервис по HTTP, как обычный клиент, гоняются параллельно и проходят за секунды. Я разбирал это на код-ревью и сначала прифигел, а потом не стал переходить на него сам, но кое-что забрал себе. В статье сравниваю оба подхода, разбираюсь где какой уместен, и показываю три вещи, которые подсмотрел и притащил в свой Spring

Codex хорош, пока не приходится в пятый раз объяснять ему одни и те же правила проекта: где проверки прав, как запускать тесты, почему не надо тащить старые alias-модули и что мы уже решали в прошлом чате.

Поэтому я сделал Hermes Codex Plugin — плагин, который хранит правила, summaries и прошлые решения в SQLite, ищет их через FTS5 и подкладывает Codex только маленький релевантный кусок контекста.