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

Работа с Claude Fable 5 раз за разом напоминает мне старую истину: карта — не территория.

Карта — это представление предстоящей работы: мои промпты, скиллы и контекст, всё, что я передаю Claude. Территория — это то, где работа реально происходит: кодовая база, реальный мир, его настоящие ограничения.

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

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

Хабр, привет! Меня зовут Сергей Бережной, я директор по взаимодействию с разработчиками в Яндексе и эксперт онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Сегодня хочу поговорить о том, почему креативность и умение думать — главные навыки разработчика в эпоху сгенерированного кода, почему ИИ — экзоскелет, а не автопилот и почему если вы используете ИИ в разработке, вы уже тимлид.

AI Engineer World's Fair 2026 уже прошла, а по-русски её так никто и не разобрал. В официальном расписании 560 сессий: воркшопы, кейноуты, доклады. Глазами это не осилить.

Я собрал агентный пайплайн, прогнал через него доступные записи и сел читать конференцию про агентов с помощью агента. Рассказываю, что в записях повторялось из доклада в доклад, куда сходится AI-инженерия и что посмотреть, если время есть только на пять роликов.

Все доступные доклады с русскими саммари, таймкодами и тематическим навигатором я собрал в отдельном SPA.

Улучшенный Spec-driven-dev. Это SDD + handoff’ы — передний край лучших мировых практик как для соло-разработки, так и для небольших команд. Это не история про рой агентов, которые в абстрактном цикле «план → код → ревью → тесты → деплой» самостоятельно везут продукт, синхронизируясь друг с другом через воркфлоу. У нас нет личного датацентра или полумиллиона долларов на токены.

В конце будет ссылка на репозиторий-шаблон, который можно скачать, или просто указать, и сказать Opus’у (Fable’у): «сделай мне такую же систему спецификаций» — дальше он справится сам.

Полгода назад я построил себе в Obsidian продуманную структуру хранилища. PARA-подобная иерархия, аккуратные папки под проекты и области, шаблоны, теги. Я честно верил, что вот теперь заживём.

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

Самое обидное, что я понимал: дело не в моей исключительной лени. Так происходит у большинства. Более того, многие вообще не начинают вести базу знаний, потому что заранее боятся этого хаоса. «У меня будет свалка из трёхсот файлов, зачем начинать». И из этой личной боли выросла идея плагина.

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

Приветствуем, Хабр.

Мы стараемся лицензировать в издательстве «O’Reilly» и переводить для вас фундаментальные книги, в том числе, по формирующимся парадигмам и подходам к разработке. Одним из наиболее успешных базовых изданий такого рода была книга «Основы инженерии данных» Джо Риса и Мэта Хоусли, вышедшая в середине 2024 года (допечатка – январь 2026). Желая развить эту тему, мы издали и вторую, возможно, не менее фундаментальную книгу «Data Engineering Design Patterns», которую написал для издательства «O’Reilly» Бартош Конечны. Русское издание вышло в конце июня и называется «Инженерия данных. Паттерны проектирования». Автор считает, что в дисциплине инженерии данных можно выделить такие же многоразовые и универсальные шаблоны проектирования типичных решений, как и в традиционном программировании. То есть, он берётся повторить в этой области фундаментальный труд «Банды четырёх», который в середине 1990-х привёл к появлению всем известной книги «Design Patterns». Ранее мы размещали статью с примерами вычленения паттернов проектирования в области инженерии данных — это был перевод, а оригинал статьи написал сам Бартош Конечны, собираясь обосновать готовящуюся книгу и очертить её тематическое поле. Под катом рассмотрим, какие именно темы вошли в новую книгу.

В 1975 году Фредерик Брукс выпустил книгу «Мифический человеко-месяц». Она появилась не потому, что он решил написать очередной учебник по менеджменту. До этого Брукс руководил разработкой операционной системы OS/360 в IBM - одного из самых масштабных программных проектов своего времени. Когда всё закончилось, ему было что рассказать.

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

Прошло больше пятидесяти лет, а эту идею до сих пор называют законом Брукса.

Это разбор ролика на канале Art of the Problem.

Поздно вечером автор проекта собирался выключить свет в комнате — и остановился, потому что робот издал звук. В логе мыслей робота было написано: “Когда же хозяин вернется? Я не хочу оставаться один”.

Автор понимал, что это не сознание. Но на секунду все равно стало не по себе… 

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

У автора возникли две мысли. Первая: роботы вот-вот пройдут “тест Тьюринга” — станут достаточно умными и достаточно ловкими, чтобы вести себя как живые. Вторая: все нужные для этого чипы и датчики уже массово производятся и стоят копейки. Прикинув расходы, автор понял, что может собрать дома, всего за сто долларов, урезанную версию проектов, которые еще недавно стоили миллиарды. Детская мечта оказалась достижимой. Робота назвали Growbot.

Привет, Хабр.

Сейчас почти каждый AI-кодинг-агент подключает LSP — Language Server Protocol. Это тот самый протокол, по которому редактор общается с языковым сервером: go-to-definition, find usages, hover с типом, диагностика. На этом обычно и пишут: «агент понимает код семантически».

Но мы в Veai делаем агента для JetBrains IDE, и нас периодически спрашивают: а зачем вообще нужен IDE, если LSP уже всё умеет? Хороший вопрос. LSP и правда решает много задач, но он проектировался для редактора, а не для агента. Подсветить ошибку, показать тип под курсором, найти ссылки — для этого LSP достаточно. А вот поменять Spring-бин в enterprise-проекте и не сломать сборку — тут нужно чуть больше.

Под катом разберём, что именно LSP даёт агенту, где этого перестаёт хватать и что поверх той же модели проекта предлагает JetBrains Platform. Спойлер: сравнивать LSP и PSI один в один бессмысленно — LSP это протокол, PSI это модель. Речь пойдёт о LSP vs весь стек IDE.

Всем привет, это моя первая статья на Хабре, и я решил посвятить ее своему недавнему мини‑проекту, сутью которого является обучение небольшого перцептрона 2-5-1 с помощью Python без сторонних библиотек (типа NumPy), и его последующий инференс на непрограммируемом инженерном калькуляторе Casio‑Fx-82-Es Plus (2^nd edition).

В качестве задачи для перцептрона я выбрал определение того, находится ли точка в пределах графика следующей лемнискаты Бернулли: (x² + y²)² — 2a²(x² — y²) = 0 (с a = sqrt(0.5), то есть вообще без коэффициента 2a²), с минимально приемлемой вероятностью (70–85%)

Всем привет!

Вероятно, часть людей уже меня знает, но всё же представлюсь. Меня зовут Михаил Поливаха, я являюсь техническим лидером проекта Axelix.

Я уже какое-то время назад выпускал статью, которая поясняла, что такое Copyright, что такое лицензия в общем её смысле, какие типы лицензий бывают и т.д. Рассматривайте данную статью как некое продолжение этой прошлой статьи.

Сегодня я хочу осветить такой момент, как CLA и почему в том или ином виде он есть у любого крупного Open Source-а. Мы также рассмотрим, как AI влияет на CLA и на принятие контрибьюшенов со стороны. Есть ещё DCO. Его, например, уже давно использует Linux, и Spring Framework в своё время перешёл на него с CLA. Но DCO, я думаю, стоит обсудить отдельно. Если интересно будет - пишите, я потрачу время, расскажу.

В общем, без долгих прелюдий, начнём.

Большинство AI‑приложений — это просто «запрос → LLM → ответ». PAD+ AI исследует, что должно происходить между этими шагами. Мы построили открытую когнитивную архитектуру с 22 фазами обработки, 6 типами памяти, эмоциональной моделью и полной трассировкой «мыслей» системы через X‑Ray. Это не чат‑бот, а инженерная платформа для наблюдения за процессом принятия решений ИИ.

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

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

Привет, Хаброжители! Сегодня мы подготовили для вас перевод статьи. Эта статья посвящена переосмыслению концепции аспектно-ориентированного программирования (АОП) в эпоху развития больших языковых моделей (LLM).

Как писать код, который одновременно корректен, эффективен и безопасен? Классическое АОП с его «точками соединения» оказалось слишком сложным. Новая парадигма предлагает описывать каждый аспект в отдельном документе, а LLM выступает в роли «плетельщика», генерируя чистый и удобный код.

Почему этот подход устойчивее и как он меняет разработку?

Переход к микросервисной архитектуре неизбежно поднимает вопрос эффективности межсервисного взаимодействия. В PHP традиционный стек на базе PHP-FPM и REST API создает дополнительные накладные расходы: каждый запрос обрабатывается в отдельном процессе, что требует повторной инициализации контейнера зависимостей, загрузки конфигурации и всего контекста приложения. В результате увеличивается latency и снижается пропускная способность сервиса.

В этой статье мы шаг за шагом разработаем высокопроизводительный микросервис на Symfony 7, используя RoadRunner в качестве постоянного приложения-сервера, gRPC для межсервисного взаимодействия и Protocol Buffers для сериализации данных. По итогам вы получите полностью рабочий сервис и поймете, как построить производительную альтернативу классическому стеку PHP-FPM + REST.

Проектная документация редко становится предметом гордости команды. Обычно это сотни артефактов, разрозненные системы, ручная синхронизация и ощущение, что половина работы уходит не на разработку, а на обслуживание процесса. Мы попробовали изменить эту логику: не отказаться от привычных инструментов, а собрать вокруг них единый контур проектирования. Рассказываем, что из этого получилось.

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

Если вы хоть немного следите за AI coding, то наверняка слышали новую мантру: IDE больше никому не нужна. Все «вайбанутые» живут в терминале, запускают Claude Code, Codex или OpenCode и уверенно объясняют, что профессиональная среда разработки — это пережиток эпохи, когда код писали руками.

Agent-у хватает самых простых инструментов: grep, bash, edit и пары хороших prompt-ов. Сложные интерфейсы, UI-инспекторы, рефакторинги, дебаггер — всё это выглядит как пережиток прошлого. Открыл терминал, написал задачу, получил diff. Кажется, человечеству IDE больше не нужна. Или всё-таки нужна? Тут как посмотреть.

JetBrains в этой картине обычно достаётся роль динозавра. Компания много лет задавала планку того, как должен выглядеть профессиональный инструмент разработчика. Но когда индустрия сместила фокус с IDE на agent-ов, предложенные JetBrains AI Chat (ex. AI Assistant) и Junie выглядели не как новый тренд, а скорее как попытка заскочить в уходящий поезд.

Но у тезиса «IDE больше не нужна» есть слабое место: он смотрит на IDE только глазами человека. А что, если следующими пользователями IDE будут не люди, а agent-ы? В компании JetBrains с закатом IDE, естественно, не согласны и предлагают своё видение: среда разработки как набор инструментов и знаний о проекте, доступных AI Agent-у.

Команда OpenIDE здесь придерживается схожей позиции: мы считаем, что IDE никуда не денется. На данный момент ни один разработчик, которого я знаю, не удалил IDE с рабочего компьютера, хотя agent-ами пользуются уже все или почти все.

Но сегодня поговорим не о том, зачем IDE нужна человеку и почему от неё не отказываются, а о том, зачем IDE нужна agent-у.

Каждый из вас, кто работал с Claude или с ChatGPT, смотрел на свои лимиты
Или задавался вопросом «Да как один запрос съел 10% от лимита»

Я потратил неделю на то, чтобы разобраться в том, а что вообще отображают эти лимиты

И на свет появилась третья статья из моей серии «А как вообще работают современные LLM»

После этой статьи ты разберёшься, что скрыто за 5-часовым лимитом Claude и других LLM и как на этом можно экономить. А еще — из каких примитивов состоят лимиты и какая физика вычислений за этим стоит

Ну а если работаешь с моделями по API, то вообще пушка бомба

Осторожно: после прочтения вы не сможете смотреть на полоску лимитов как прежде 🥵

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

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

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

Что же я хотел? Я хотел сравнить свои программы и программы, написанные ИИ. Но эксперимент должен быть серьезным, поэтому статья ожидается достаточно большой, особенно с учетом публикации кодов...