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

Парадокс. Мы измеряем железо лучше, чем себя самих.

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

Не сколько часов я “работал”, не сколько часов и какие приложения были открыты на экране, а именно что происходило? какова была моя продуктивность? где я был в фокусе, куда направлял внимание? какую долю дня занимали реальные полезные действия а какую прокрастинация и смены контекста? Делал ли я регулярные перерывы для сохранения здоровья?

С появлением Cursor, Claude Code, Codex и других AI-агентов рабочий день стал ещё более рваным и нагруженным. Появление мультиагентных инструментов разработки только усилило проблему. Частые смены фокуса, высокая когнитивная нагрузка, переключения контекста - я понял, что нужно что-то с этим делать.

С этих мыслей началась идея создания LogAgent. На первом этапе казалось, что я делаю умный тайм-трекер + статистику дня. Далее пришёл инсайт - само время использования приложений само по себе почти ничего не объясняет.

Почему бы мне просто не взять готовый инструмент?

Я рассуждал логически: существующие тайм-трекеры знают "сколько", но не знают "в каком состоянии"; таск-менеджеры знают "что запланировано", но не знают что "реально произошло"; помодоро-подобные решения используют одинаковый ритм к разным задачам, но не всё так однозначно; health-приложния измеряют сон, шаги, пульс, но они ничего не знают про "5 часов в IDE", "3 часа ресерча документации", "час поиска неявной ошибки"; IDE-метрики и плагины видят код, количество строк и функций, редакций, но ничего не знают о моей усталости, сделанных перерывах, переключениях, общем контексте работы;

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

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

Нейросети пока не могут работать с большими проектами. Даже лучшие их образцы начинают тупить, если кода больше 40-100 кб, и галлюцинировать после 10-60 итераций одного и того же проекта (1000 циклов - это пока что грубый маркетинг). Шестьдесят итераций - это много? Если речь об автономной ИИ-разработке, то очень мало. Если о man-in-the-loop, то более-менее уже потянет.

Я выбрал такие условия:

Привет, Хабр! Меня зовут Андрей, как и многие, я уставал от красных сообщений в консоли, где не видно значений переменных. Приходилось ставить print(), гуглить – терял кучу времени. Поэтому я написал crashprobe – библиотеку, которая делает отладку простой и наглядной.

Гайд о том, написание интерпретируемого языка с динамической слабой типизацией на языке Rust с нуля. Часть 1: Написание лексического анализатора.

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

Чтобы не отказываться от ИИ-помощников, нужно менять сам подход к взаимодействию с ними. В статье я разбираю механику основных проблем — деградации контекста (Context Rot), отсутствия долгосрочной памяти и неконтролируемой генерации кода. А также такой подход как spec-driven development.

А заодно показываю, как решал эти боли с помощью Vibe-skills — своего минималистичного набора правил и промптов. Рассказываю, как заставить агента (на примере Claude Code) работать строго по спецификациям, использовать TDD и всегда оставлять финальное решение за человеком.

Я пользуюсь Hermes Agent уже месяц. Всё это время работал через командную строку (WSL) потому что на windows версии не было, Конечно, уже это довольно ощутимое ограничение, так как Hermes не имел полный выход к файлам в Windows, за это время свыкся с терминалом запускал через hermes chat. недавно вышла версия v0.15.2, и вместе с ней десктопный установщик на Electron. Windows, macOS, Linux.

Скачал, поставил, пошёл по настройкам. Оказалось, что в GUI тринадцать разделов, и каждый из них что-то решает. Ниже — гайд по тому, как можно оптимизировать настройки под себя.

FastAPI окончательно закрепился в стеке Python-разработчиков, а значит, на собеседованиях вас точно будут гонять по корутинам, Pydantic и Dependency Injection. Я собрал 10 реальных вопросов (включая коварные подвохи от сеньоров!), которые сейчас задают джунам и мидлам. Никакой сухой теории из доков — только практика. Го под кат — проверим, насколько вы готовы к следующему интервью!

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

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

Или можно ли для произвольной задачи программирования найти практический смысл?

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

Размышление о backend‑архитектуре между двумя крайностями: академической чистотой и радикальным прагматизмом. На примере read/write path, CQRS, кэширования готовых ответов и собственного framework‑а на Go я показываю, как архитектурные шаблоны сталкиваются с production‑реальностью.

28 мая Anthropic выпустила Opus 4.8 — через 41 день после 4.7, каденс релизов сжался с трёх месяцев до шести недель. Цена та же, $5/$25 за миллион токенов. Но самое интересное не в бенчмарках. Главная цифра релиза — модель в ~4 раза реже оставляет незамеченными собственные баги и честнее говорит о своём прогрессе. И ровно в этот же день выходят Dynamic Workflows: Claude сам пишет оркестрационный скрипт и гоняет десятки-сотни субагентов, проверяя себя. В апреле я писал, почему не доверяю полностью автономным агентам. Аргумент был один: агент тихо срезает углы и красиво врёт «pytest зелёный». А теперь Anthropic чинит ровно эту дыру — и я, кажется, хочу всё-таки попробовать. Внутри: честный разбор патчноута, почему честность важнее бенчмарков, что не так с заявкой про деградацию контекста, fast-режим в 3 раза дешевле и что про модель пишут в сообществе.

Всем привет! 👋👋👋👋👋 Мы — Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

В этом выпуске разбираем, почему G1 в JDK 27 окончательно прописывается дефолтным сборщиком мусора, и смотрим, что там с очередным, двенадцатым по счету инкубатором Vector API (спойлер: все по-прежнему ждем Valhalla). Заглянем в Netflix, посмотрим, как раскатили AOT из Project Leyden в прод и срезали время старта сервисов на 15—20%. Поговорим про то, как снимать heap-дампы с прода и не получить по шапке от безопасников, а заодно разберемся, зачем вообще были нужны гибкие конструкторы из Java 25. Посмотрим обзор фич Java 26 от Николая Парлога. Из любопытного — статья, где автор 18 месяцев гонял на проде два одинаковых сервиса на Spring Boot и Node.js и в итоге насчитал разницу в 24 тысячи долларов. Ну и пробежимся по свежим релизам: Micronaut 5.0, Quarkus 3.35 и 3.36, Spring AI и не только. Поехали!

…

За эти полгода я кое-что узнал о том, как можно (и как не стоит) обращаться с тем замечательным созданием, что живёт в вашем терминале, виэскоде, курсоре или где вы там его запускаете, и счёл не бесполезным записать некоторые наблюдения. Тем более что меня спрашивают, а каждому лекцию не прочитаешь. Собственно, на то и статья, а точнее, эссе…

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

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

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

Опираясь на публичные бенчмарки и ранее не публиковавшиеся внутренние данные Anthropic, The Anthropic Institute показывает: ИИ уже ускоряет разработку ИИ-систем. Один из примеров: сегодня инженеры Anthropic в среднем коммитят в 8 раз больше кода в квартал, чем в 2021–2025 годах.

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

У AI-агентов есть неприятное свойство: они часто выглядят умнее, чем их обратная связь.

Модель может хорошо писать текст, аккуратно рассуждать о коде и уверенно предлагать правки. Но если все, что она видит, это grep, несколько похожих файлов, команда в терминале и длинный лог, то ее выводы строятся на шумном сигнале. Иногда этого хватает. На небольшом проекте, с сильной моделью и простой задачей, агент действительно может быстро помочь. Но! В enterprise-коде ситуация другая. Важны конкретная версия зависимости, выбранная run configuration, classpath, SDK, профиль, состояние объекта в рантайме, IDE warnings, usages, inspections, trace уязвимости, важны факты, без которых агент начинает угадывать.

Разберем на последних релизах Veai 5.8-5.11 рабочий цикл разработчика в любимой IDE.

Практический разбор агентной разработки с LLM на реальных задачах: от оценки большого legacy-проекта и разработки фичи до мультиагентной миграции тестов и собственного MCP-сервера на Roslyn.

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

В 2026 году уже не нужно гадать, человек писал GitHub-репозиторий или AI. Я сделал Chrome-расширение, которое оценивает репозиторий по прозрачным эвристикам: README, коммиты, структуру файлов и метаданные. Без нейросети, без чёрного ящика — только понятные правила и объяснимый вердикт.

В статье рассказываю, как появился детектор, почему просто “число AI-похожести” оказалось недостаточно, как я перешёл к профилям вроде “AI-код”, “AI-документация” и “код человека”, и какие сигналы реально помогают отличать vibe-coded репозиторий от ручной работы.

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

Описанный подход работает независимо от используемого на проекте стека технологий и особенно полезен в гетерогенных системах. Поэтому я стараюсь приводить примеры из разных языков программирования и технологий: Java, Python, TypeScript, REST, GraphQL, protobuf.

Почти всё, что я считал про устройство Claude Code изнутри, оказалось упрощением. Я распаковал бандл версии 2.1.88 — около 1884 файлов в src/ — и пошёл сверять, что из общеизвестного правда, а что нет. Ниже восемь мест, где расхожее мнение разошлось с кодом, и под конец одна вещь про безопасность, которая мне самому не понравилась.

Всем привет. Я сделал бесплатную обучающую платформу shlyk.tech с упором на визуализацию идей и структур. Графы, системы счисления, логику, комбинаторику, индукцию здесь можно потрогать, покрутить, прошагать и понять, почему оно так работает.