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

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

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

Друзья, знаю, что интернет переполнен воспеванием AI, что вызывает у многих людей (особенно специалистов) фрустрацию, особенно когда речь заходит о написании кода на C/C++. Я не AI-проповедник – просто активный и ответственный программист, который пользуется AI-инструментами. Недавно я предложил AI (если быть точнее, opencode + GLM-5.1) придумать алгоритм для одной из задач, над которой я работаю, и он справился очень хорошо. Это не прорывной алгоритм, на котором я разбогатею, но он интересный: составленный из известных компонентов, но всё же новый. В статье расскажу:

Как решать задачу “дана битовая строка, нужно найти все позиции в ней, что количество единиц минус количество нулей до этой позиции равно заданному числу”

Что мне придумал AI для этой задачи

Что я использую для того, чтобы AI писал что-то адекватное на C++

Если вам интересны алгоритмы и структуры данных, то описанная задача используется в контексте RMQ/LCA.

Есть задачи, в которых мы понимаем, чего нужно добиться, но не можем описать путь к цели. И когда способ достижения цели либо слишком сложен, либо совсем неизвестен, решение находится в процессе проб и улучшений. Так работает эволюция. У нее нет конкретного плана по дизайну организма, но есть цель: существо должно быть достаточно приспособленным к среде, чтобы выжить. 

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

Один из способов понять как возникает сложность — это попробовать создать ее самому. 

Поэтому мы поговорим об эволюционных алгоритмах на примере созданной модели GUCA (Graph Unfolding Cellular Automata). Ее можно запустить на компьютере, чтобы проверять гипотезы и находить закономерности: какие изменения приводят к прогрессу, какие — к стагнации, а какие — к эффектным, но бессмысленным решениям.

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

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

То, что я наблюдаю в своём профессиональном поле на протяжении двух последних лет, сложно описать. Первый явный звоночек я заметил чуть меньше, чем полтора года назад. Тогда я обратил внимание, что коллега отвечает мне в переписке с помощью ИИ. Его выдала пунктуация — длинные тире там, где их никто не использует; ритмическая структура текста и уверенное рассуждение на тему технологий, в которых он заведомо не разбирался.

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

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

Довольно интересное наблюдение: я перестал пользоваться автокомплитом в IDE, который предлагает LLM.

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

Вы всё ещё используете map и filter с лямбдами в 2026 году? Подготовил большой гайд по анонимным функциям в Python: от самого первого lambda x для новичков до разбора байт-кода, замыканий и жестких антипаттернов, за которые бьют по рукам на код-ревью.

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

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

Всем привет! Меня зовут Макс, я Lead Backend и автор YouTube‑канала PyLounge. 

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

В этом же материале поговорим о самом интересном: что происходит, когда python manage.py migrate запускается в 17:30 в пятницу на проде, под 3k RPS и таблицей в 200 миллионов строк. 

Расскажу какие блокировки в PostgreSQL берёт каждая операция Django, что внутри atomic = False, как пишется правильный паттерн expand‑migrate‑contract, зачемнужны AddIndexConcurrently, AddConstraintNotValid, SeparateDatabaseAndState и как обновлять данные на больших таблицах.

P. S. примеры намеренно упрощены, чтобы влезли в статью и не задушили. В реальной жизни всё ещё хуже — но шаги те же.

P. S.S. При подготовки этого материала ни одна продовая база данных не пострадала. 

Полтора года в Claude Code, несколько релизов моделей, десятки экспериментов с командой в Kaiten. Всё это время я ждал, что главным рычагом качества будет очередной релиз модели. Оказалось, ровно наоборот: смена модели даёт заметный, но ограниченный прирост, а каждый новый слой обвязки вокруг неё — кратный.

Англоязычные инженеры называют эту обвязку harness. Это контур, в котором живёт модель: системный промпт, инструменты, контекст, скиллы, хуки, разрешения и память. Без него даже флагманский Claude или Codex работает как экскаватор без рычагов — мощность есть, использовать нечем. У русского аналога одного короткого слова пока нет, поэтому ниже — harness и обвязка вперемешку.

Все началось с прикола, я сидел с друзьями и подумал, а вот было бы прикольно запихать разные модели нейросетей в один чат и заставить их думать, что они реальные люди и работают в корпорации. Весь смысл был в том, чтобы это были действительно разные модели и пользователь мог просто между ними переключаться по запросу. Для начала мне нужно было найти зоопарк апи ключей с бесплатными лимитами. Я прошерстил весь интернет и в итоге нашел относительно норм варианты: Groq для LLama, Google AI Studio для Gemma и Gemini. В целом в это время код был простой, правда все время происходил забавный баг, когда пользователь переключался между моделями, одна модель не хотела отдавать очередь другой и просто притворялась ею, но я в целом без трудностей поправил это через системный промт. Однако до конца у меня исправить это так и не получилось, видимо, мои модели слишком тупые.

Полгода использовал Claude, GPT и Cursor как полноценного второго разработчика на Rust в проде. Собрал семь категорий ошибок, которые модели стабильно делают и которые проходят cargo build, cargo test, иногда cargo clippy и при этом являются UB или скрытыми архитектурными ловушками. Lifetime laundering, std::sync::Mutex через .await, Drop у транзакций, unaligned read, async cancellation, orphan rule и массивы на стеке. Разбираю, почему именно Rust ломает LLM и что с этим делать.

Программирование — это редко про «написать кнопку». Чаще это попытка перевести хаос бизнес-процессов, привычек пользователей и странных требований в систему, которая должна работать стабильно. В статье — реальные истории из легаси, enterprise и автоматизации: DOS-мышление в вебе, Excel как основа бизнеса, реверс-инжиниринг без документации и почему иногда лучший аналитик — оператор с цифровым блоком клавиатуры.

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch? Там ведь код тривиальный! Но это только на первый взгляд.

Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…

Плагин для JetBrains-IDE, который встраивает полноценный Telegram прямо в редактор. Плюс шифрованный шеринг кода, подсветка синтаксиса в теме получателя и магия с метаданными в обычном тексте сообщения. Разбираю изнутри.

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

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

Я три года пилю Telegram-бот для одного B2C-продукта. В пятницу вечером маркетолог попросил убрать запятую — я потратил двадцать минут на одну запятую, потому что текст был размазан по семи питон-файлам. И тут меня переклинило. Так появилась библиотека, где все диалоги бота живут в одном YAML — с клавиатурами, медиа, условиями и опциональной очередью под лимит Telegram. Выложил на PyPI, делюсь.

В Kotlin деструктурирование выглядело так: val (name, age) = person. Но компилятор берет значения не по именам, а по позиции component1/component2.

Отсюда проблемы. Если поменяли порядок параметров в data class или сделали age вычисляемым свойством: то та же строка начинает доставать другое поле. Причем иногда код даже скомпилируется, но, конечно, смысл изменится: val (age, name) = person.

И вот теперь Kotlin эксперементально переводит круглые скобки на деструктурирование по имени. Синтаксис будет такой: (val name, val age) = person. И порядок внутри скобок не важен. Переименование явно: (val years = age, val theName = name) = person.

Позиционное же деструктурирование остается, но переезжает в квадратные скобки для Pair/Triple и коллекций: val [x, y] = point.

Разбираемся полностью в новом переводе от команды Spring АйО.

Более тридцати лет назад норвежские разработчики Ховард Норд и Эйрик Чамбэ-Энг создали Qt — фреймворк, которому суждено было стать стандартом де-факто для кроссплатформенной разработки. Широкому распространению Qt во многом способствовал Маттиас Эттрих: основатель проекта KDE выбрал его в качестве фундамента этой среды, а затем занял руководящую позицию в команде разработчиков Qt. А уж тем более трудно было предвидеть, что у Qt появится свой «летописец» в России, книги которого разойдутся тиражом более 25 000 экземпляров.

Вот как сам Эттрих напутствовал читателей в первом издании книги Макса Шлее:"Давайте начнём с вымышленной истории. Представьте, десять лет назад кто-то пришёл ко мне и спросил: «Возможно ли написать многофункциональное графическое приложение, а затем скомпилировать и запустить его на всех основных операционных системах? На Linux, на UNIX, на Windows и на Macintosh?» Тогда — будучи молодым прграммистом — я, вероятно, ответил бы: «Нет, это невозможно. А если бы и было возможно, то система была бы очень сложной в использовании и ограниченной самой слабой платформой. Лучше выберите одну платформу или напишите свой код несколько раз». Несколько лет спустя я открыл для себя Qt — и понял, как сильно я ошибался! Qt делает настоящую кроссплатформенную разработку реальностью, не ограничивая ваш выбор и творчество. Слишком хорошо, чтобы быть правдой? Не верите? Что ж, доказать легко. Я передаю слово Максу, который расскажет вам, как именно это делается. Макс, твой выход.

В прошлой статье я поделился своими наработками в области работы ИИ с CAD-программами (в моём и нашем случае, SolidWorks). В этот раз поделюсь практическими результатами на примере тестового ядра своей программы.

В статье поделюсь тестами программы, опишу интерфейс и поделюсь мыслями о дальнейшем развитии.

200 задач. 248 тысяч тестов. Девять моделей, среди них всё свежее: Opus 4.7, GPT 5.4, Gemini 3.1 Pro, Sonnet 4.6. На SWE-bench те же модели берут 70 % и выше. На ProgramBench — ноль полного резолва. Лучший «почти решено» у Opus 4.7 — 3 %. У остальных и того нет. Это новый бенчмарк от Meta Superintelligence Labs, Stanford и Harvard (2026). Агенту дают скомпилированный бинарь и описание программы. Никаких сорсов, никакой декомпиляции, никакого интернета. Задача — собрать программу с нуля так, чтобы она прошла 248 тысяч поведенческих тестов. Это не «пофиксить баг в существующем коде» (как SWE-bench) и не «дописать функцию по сигнатуре» (как HumanEval). Это другой ТИП задачи: спроектировать систему. Внутри — методология, паттерн результатов (что модели вытягивают, а что нет), и почему этот ноль — на самом деле важная новость для тех, кто строит на LLM продакшен.