Планирование, отслеживание и контроль
На днях наткнулся на статью про память для AI-агентов.
Сама статья была вполне типичной: SQLite, хранение контекста, поиск по накопленным знаниям, экономия токенов.
Но гораздо интереснее оказались комментарии.
Под публикацией быстро возник спор, который на первый взгляд выглядел техническим.
Одни утверждали:
За последний год вокруг AI-агентов сформировался довольно устойчивый набор ожиданий.
Нам обещают всё более умные модели, всё более длинные контекстные окна, всё более автономных агентов. Создаётся впечатление, что осталось решить ещё пару технических проблем — и агент сможет самостоятельно разрабатывать сложные проекты почти без участия человека.
Я тоже так думал.
В команде могут быть спринты, дейли и ретроспективы, а работа при этом годами оставаться обычным водопадом под вывеской Agile. В 2026 году такую подмену стало проще заметить: ИИ быстро забирает рутинные церемонии и показывает, где процесс действительно помогает команде, а где лишь производит отчёты и артефакты. В этой статье разберём семь признаков Agile-театра и способы вернуть практикам смысл.
Последнее время слышу про новый вид долга — когнитивный. Это когда код пишется быстрее, чем люди успевают его понять и взять под контроль. В статье обсудим этот феномен: расскажу, есть ли когнитивный долг у нас в Профи.ру и что собираемся делать с ним дальше.
Последнее время я всё чаще встречаю одну и ту же мысль: бизнес никогда не даст ИИ‑агенту доступ к базе клиентов, заявкам, платежам, CRM или внутренним документам. На первый взгляд звучит логично. Если агент ошибётся, перепутает контекст или выполнит не то действие, ущерб может быть вполне реальным. Но мне кажется, что здесь часто путают две разные вещи.
Давать агенту прямой доступ к базе действительно нельзя. А вот давать ему возможность работать через ограниченный, проверяемый и журналируемый контур действий вполне можно. Примерно так же мы не даём пользователю прямой доступ к PostgreSQL, но разрешаем ему нажимать кнопки в интерфейсе, которые вызывают заранее описанную бизнес‑логику.
В этой статье я хочу как раз таки разобрать, как может выглядеть такой контур на практике: без магии, без «агент всё сам решит», без сырого SQL от модели и без веры в то, что хороший prompt заменяет нормальную архитектуру.
Технический долг есть почти в любой системе. Но в какой момент он превращается из разумного компромисса в фактор, который замедляет разработку, увеличивает число ошибок и делает каждую новую фичу дороже предыдущей?
В статье разбираем, как измерять архитектурный долг через метрики, находить реальные точки трения и не допускать превращения проекта в Big Ball of Mud.
Код работает, тесты зелёные — а читать его невозможно.
Документация «содержит всё» — а в голове после неё не остаётся ничего.
Привычный диагноз «плохо обучили» объясняет не всё: человек и LLM мыслят по-разному устроенными механизмами, и значительная часть «низкого качества» — это столкновение двух когнитивных архитектур.
Где на самом деле предел внимания LLM, почему у человека сложность болит, а у модели нет, и кто в системе «человек + LLM» заметит момент потери контроля.
Спойлер: никто.
С код-ревью есть такой парадокс: все согласны, что он важен, но времени на него обычно ни у кого нет. В результате ревью часто превращается в формальность. Очевидные баги при этом ловятся, а мелкие, вроде пропуска в условиях, перепутанные знаки, забытые edge cases и т.д., могут спокойно уехать в мердж и вернуться уже в виде задач в багтрекере.
В Content AI мы активно внедряем ИИ в разработку, и одна из задач, которую мы решали в этом году, — автоматизация код-ревью. В этой статье рассказываем, как одна из наших команд собрала ИИ-ревьюера, встроенного в Pull Request, и что мы поняли спустя месяц использования.
ИИ-ревью кода уже умеет находить пропущенные тесты, типовые уязвимости и спорные места в пулл-реквестах. Однако его реальная точность зависит прежде всего от контекста, который видит модель, и от того, насколько хорошо команда фильтрует шум.
Разбираемся, как устроены такие системы, где они действительно ускоряют разработку и почему слишком раннее доверие к ним может обернуться пропущенными регрессиями.
Всем привет, меня зовут Михаил, я работаю главным экспертом в ОТП Банке.
До банка я почти не работал в командах с выстроенными процессами. Суета, спешка, неадекватные сроки, переработки до ночи и постоянное тушение пожаров - всё это было привычной частью работы. Я видел, как команды выгорали, а проекты разваливались из-за отсутствия процессов.
В какой-то момент я сказал себе: «Стоп. Хватит. Пора уходить в компанию, где всё организовано правильно». Мне казалось, что там не будет хаоса, бессмысленных авралов и вечной гонки за дедлайнами.
Ну что могу сказать - я попал.
Только вот ожидания и реальность оказались совершенно разными.
В этой статье я расскажу, всегда ли выстроенные процессы идут на пользу, скучаю ли я по тому самому рабочему хаосу и что в итоге выбрать разработчику: свободу и скорость или предсказуемость и порядок.
Привет! Я — Мария, руководитель направления автоматизации процессов управленческого учета, бюджетирования и контроля расходов.
На проектах регулярно сталкиваюсь с тем, что в организации автоматизировали согласование заявок на расходы, но вопросы о свободных лимитах, обязательствах и план-факте по-прежнему приходится решать вручную.
Со стороны это выглядит странно: автоматизация есть, а полноценного бюджетного контроля нет.
В этой статье я хочу посмотреть на проблему с архитектурной точки зрения. Разберем жизненный цикл бюджетного лимита и пять типовых разрывов процесса, которые чаще всего становятся причиной возврата к Excel-сверкам, ручному план-факту и спорам о доступном бюджете уже после внедрения.
Статья будет интересна бизнес-аналитикам, архитекторам, руководителям проектов автоматизации, а также сотрудникам финансовых подразделений, участвующим в развитии бюджетного процесса и управленческой отчетности.
Последние пару лет, кажется, невозможно поговорить об AI в разработке, чтобы разговор не упирался в тему производительности.
Отовсюду постоянно вылезают новые истории успеха. Кто-то показывает, как сократил время разработки в несколько раз. Кто-то рассказывает, что теперь пишет за день столько кода, сколько раньше писал за неделю. Иные вообще собирают полноценный продукт за выходные и искренне не понимают, почему раньше на это уходили месяцы. Честно говоря – раньше читал, но в последнее время просто игнорирую такие заголовки (почему – надеюсь станет понятно из статьи).
В общем, начинает возникать ощущение, что индустрия наконец приближается к своей заветной мечте: программирование становится быстрее, а создание продукта дешевле и доступнее.
И мы, с моей командой проходим через те же изменения, что и вся индустрия.
Redmine до сих пор делает своё дело — бесплатно, стабильно, на вашем железе. Если у вас 15 человек и настроенный процесс, возможно, менять ничего и не надо. А если упёрлись в плагины и человеко-часы — разбираем 10 альтернатив: с честными минусами, реальной ценой миграции и советом, как не перевезти в новую систему свои 25 кастомных статусов.
Если вы пишете код, или так или иначе задействованы в разработке ПО, или просто следите за тем, как ИИ меняет разработку, то наверняка слышали тревожный тезис: «Скоро ИИ будет писать код лучше людей, и разработчики станут не нужны». На интуитивном уровне кажется, что если машина делает ту же работу в 8 раз быстрее, то бизнесу нужно в 8 раз меньше людей. Но экономика и история индустрии говорят об обратном — и тут очень кстати оказывается старый экономический парадокс, которому уже больше 150 лет.
ИИ, большие языковые модели, ассистенты, агенты — нам обещали безграничную свободу и автоматизацию, но на практике отсыпали еще больше ограничений, правил и страхов.
В итоге мы получаем длинные списки запретов, требований по безопасности и постоянно переживаем, что любой промпт может случайно спровоцировать утечку.
Но я не хочу добавлять вам головной боли и нагнетать, поэтому расскажу про guardrails на примере всеми любимых мультфильмов и сказок — мы же не грустить сюда пришли.
Меня зовут Юлия Аравина, я карьерный стратег и коуч IT-руководителей, а также ведущая кейс-клубов на курсе «Технический директор — СТО» в Яндекс Практикуме PRO. В своей практике я замечаю одну закономерность: многие кризисы после повышения выглядят одинаково.
Человек становится тимлидом, и сначала всё идёт хорошо. Но через несколько месяцев начинает происходить что-то странное: он работает больше, несёт большую ответственность, принимает более сложные решения — и при этом всё чаще думает: «Кажется, я стал хуже работать». Появляется тревога, синдром самозванца, хроническая усталость от встреч.
Многие объясняют это нехваткой навыков: кажется, что нужно лучше делегировать, увереннее принимать решения или пройти ещё один курс по менеджменту. Но чаще всего проблема глубже. После повышения человеку приходится перестраивать не только набор навыков, ему приходится заново отвечать на вопрос: «За что я вообще себя уважаю?»
Давайте разбираться.
Всем привет! Я создал инструмент для разработки AIDD и назвал его Spawn. Это Python-утилита, которая помогает когерентно использовать несколько AIDD-методологий в одном репозитории — без ручной синхронизации правил, скилов и MCP-конфигов между ними.
Далее — краткое введение, затем я расскажу, как работает Spawn, как им пользоваться с клиентской точки зрения, как разрабатывать расширения, и приведу несколько примеров.
Каждый раз, когда техно-энтузиасты на Хабре начинают петь оды ИИ, который вот-вот заменит всех разработчиков, меня охватывает легкий скепсис. Дело в том, что многие простые задачи совсем не так просты, как кажутся нейросетям или продакту. Знаменитое: “да что там делать, вон ИИ отдай, к вечеру уже на прод зальете”, обычно открывает такую кроличью нору, что проваливаться и падать там можно неделями, а приземление оказывается очень болезненным.
Вот казалось бы, что сложного, сделать дверь в игре? В 2014 году у Liz England вышло отличное эссе “Проблема Двери”, где Лиза описывает 22 логических вопроса, на которые должен ответить гейм-дизайнер при установке двери в игре. Эссе стало настолько классическим, что в сабредите r/GameDesign автомод прикрепляет ссылку на него в каждый тред. При этом эссе явно выходит за границы геймдева и становится универсальным, показывая, что кажущаяся простота в нашем деле часто не является таковой. Это касается и дверей в игре, и “просто логина на сайте”, и задачи вызова лифта, и визуализации прогресса ожидания и ещё тысячи вещей, необходимость детального продумывания которых менеджментом обычно в расчет не берется.
Привет! Меня зовут Дарья Воронкина. Я строила и руководила командой DataHub в медтех-компании OneCell (цифровая патология — ИИ ищет опухоли и метастазы на гистологических стеклах), а сейчас консультирую компании по переходу в AI-native режим.
Расскажу, как примерно за месяц я перевела свою команду с ручных промптов на систему агентов, которая ведет операционку сама. Получилось быстро во многом потому, что за плечами годы ML-инженерии и роль лида — я уже привыкла мыслить системами, данными и процессами, оставалось переложить это на агентов. Дальше — что получилось, что сломалось и какие выводы я унесла. Будет полезно тем, кто уже собирает агентов и хочет довести их до прода.
Привет, Хабр. Меня зовут Василий Щитов. Я старший инженер в команде CI-инфраструктуры ВКонтакте.
Когда в компании десятки проектов и сотни сборок, ручное управление конфигурациями через UI быстро превращается в хаос. Внести однотипное изменение во все пайплайны, отследить историю правок или быстро развернуть окружение на новом инстансе TeamCity становится нетривиальной задачей. Можно превратить этот хаос в упорядоченную структуру, если описать конфигурацию как код с помощью Kotlin DSL. Но далеко не все понимают, как работать с Kotlin DSL для решения своих задач.
Я расскажу об основных подходах и паттернах, которые мы применяем, чтобы облегчить жизнь при работе с TeamCity.