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

Главная ценность релиза — разработчик начинает с рабочей задачи, а не с выбора режима.

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

Для этого в Veai 5.12 появился General Agent. Он принимает задачу в том виде, в каком разработчик обычно ее формулирует: неидеально, с сомнениями и неполным пониманием пути. Агент сам подбирает нужные действия и отдает результат, который уже можно проверить.

Попробовать Veai 5.12 · Что входит в релиз

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

Создаю собственный DSL на C#: рассказываю о том, как инкрементальный парсер. И наконец-то будет использовать одно из преимуществ рослиновской модели синтаксиса.

Привет, Хабр. Меня зовут Егор, я QA Fullstack Java в SENSE на проекте российского банка.

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

Если вы пишете код, или так или иначе задействованы в разработке ПО, или просто следите за тем, как ИИ меняет разработку, то наверняка слышали тревожный тезис: «Скоро ИИ будет писать код лучше людей, и разработчики станут не нужны». На интуитивном уровне кажется, что если машина делает ту же работу в 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-приложения и выполнять качественный первичный анализ.

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

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