Управление разработкой *

Последние пару лет, кажется, невозможно поговорить об 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.

Производственник, который пришёл в IT. О том, почему до кода надо идти в цех.

Несколько лет назад наблюдал проект на одном производственном предприятии. Небольшое производство, человек 200. До нашего проекта руководство уже наняло специалистов 1С и начало автоматизировать учёт движения сырья и управленческую отчётность по сменам.

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

К концу внедрения 1С дошло: эти 30% операций никуда не делись.

Просто переехали из бумаги в 1С. Только теперь в красивом интерфейсе.

Всем привет, меня зовут Катя, я развиваю Gramax. Уже несколько месяцев мы делаем ИИ-агента для работы с текстом и документацией, поэтому много смотрим на реальные кейсы в разных компаниях. Один из самых сильных принесли друзья из SellOut+. Они делают аналитические системы для фармы и FMCG, быстро пробуют новые подходы и в какой-то момент взяли первую версию функции агентов в Gramax.

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

Небольшой R&D о современных альтернативах Electron для десктоп‑приложений на веб‑технологиях. На одинаковом тестовом приложении (React + TypeScript + Vite) сравниваются ElectroBun, NeutralinoJS и Wails: как устроена их архитектура, каким образом они взаимодействуют с ОС, что происходит под капотом и почему результаты по памяти так сильно отличаются. В статье есть практические наблюдения, замеры потребления ОЗУ, плюсы и минусы каждого подхода, а также рекомендации, в каких сценариях выбирать минималистичный WebView‑подход, полноценный backend на Go или браузерный рантайм с максимально широкой поддержкой Web API и графики.

В прошлой части цикла мы подготовили фундамент будущего РБПО: развернули виртуальные машины, настроили Ubuntu Server, сеть, брандмауэр и Docker. Другими словами, построили площадку, на которой теперь можно начинать возводить сам конвейер безопасной разработки.

Теперь пора наполнять наши виртуальные машины полезным содержимым. Если продолжать сказочную аналогию — заселим наше царство безопасной разработки первыми жителями: хранителем секретов, смотрителем артефактов, летописцем уязвимостей и прочими полезными персонажами. То есть установим и настроим GitLab, Nexus, HashiCorp Vault, DefectDojo и Dependency-Track, а также подготовим отдельную виртуальную машину с набором CLI-инструментов для анализа безопасности.

Большая часть сервисов будет работать в Docker-контейнерах, поэтому заодно разберемся с настройкой постоянного хранения данных, Docker Compose и некоторыми особенностями конфигурации отдельных компонентов.

Что ж, глаза боятся, а руки команды в терминале набирают. Начнем с GitLab.

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Недавно мы вчетвером с QA-командой нашли способ оптимизировать нашу работу и сэкономить время на написание тест-кейсов и чек-листов с помощью автоматизирующего рутину бота. На всю разработку у нас ушло около двух недель, а в продакшене бот живёт с апреля 2026 года. Расскажу, как мы это сделали и какие результаты получили в итоге.

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

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

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

Как сделать изменения, вносимые с помощью LLM, управляемыми, проверяемыми и воспроизводимыми.

Программные ассистенты LLM продемонстрировали значительную ценность, но в основном для отдельных разработчиков. Внутренняя ИТ-организация Thoughtworks использует их для своих команд и разработала метод и рабочий процесс, называемый структурированной разработкой на основе промптов (Structured Prompt-Driven Development, SPDD). В одноименной статье Вэй Чжан и Джесси Цзе Ся, опубликованной на сайте Мартина Фаулера, описывается простой пример этого рабочего процесса с подробностями на GitHub. Этот рабочий процесс рассматривает промпты как артефакт первого класса, хранящийся вместе с кодом в системе контроля версий и используемый для согласования разработки с потребностями бизнеса. Авторы обнаружили, что разработчикам для эффективной работы необходимы три ключевых навыка: согласованность, подход «сначала абстракция» и итеративный анализ.

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

Последние месяцы я гонял другой подход: не «чат, который пишет код», а AI-команда, которая закрывает полный цикл разработки — от формулировки задачи до выката на прод, с планированием, постановкой тикетов, код-ревью, тестами на dev-окружении и автоматическим деплоем. Между этапами ничего не разваливается, потому что система устроена примерно как нормальная команда людей, только роли играют саб-агенты.

В этой статье разберу архитектуру целиком: из чего она собрана, почему именно так, и где проходят границы, за которые я агентам выходить не даю. В качестве подопытного — мой pet-проект, обычный Telegram-бот на Go (MongoDB, Kubernetes). Что именно он делает — выходит за рамки статьи; важно, что это работающий продакшен с реальными пользователями, а не песочница.

Всем привет, меня зовут Максим Колмогоров, и я технический директор VVERH DIGITAL. Эта статья — не какой-то «гайд», тем более не пособие по тому, как делать или не надо делать, а лишь описание моего личного опыта: насколько AI-assisted-разработка влияет на производительность и финансы обычной аутсорсинговой IT-компании.

Вы почти наверняка уже встречались с Conventional Commits. Их уродливые лица можно заметить в changelog опенсорсного проекта, которым вы пользовались. Возможно, это был обязательный формат коммитов опенсорсного проекта, в котором вы были контрибьютором. Многие люди безгранично им верят. Я им безгранично не верю.

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