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

Любители вайбкодинга и агентного программирования говорят, что работают в 2, 10, а то и в 100 раз продуктивнее! Один даже разработал с нуля целый браузер. Невероятно!

И скептики задают правомерный вопрос: «А где же все эти приложения?» Если пользователи ИИ становятся пусть хотя бы вдвое продуктивнее, то где искать этот двухкратный прирост созданных программ? Все подобные вопросы исходят из предположения, что миру нужно больше ПО, и если оно станет дешевле в производстве, то и создавать его будут больше. Так что, если вы с этим предположением согласны, то где же все эти дополнительные программы, которые можно было бы отнести к «эффекту ИИ»?

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

Привет. Меня зовут Вадим, в разработке очень давно — поучаствовал во всём чём можно: стартапы, продуктовые команды, инфра, питчи, продажи. Последнее время плотно живу в терминальных AI-агентах: Claude, Codex, и всё что появляется каждую неделю.

В какой-то момент заметил — инструменты стали умнее, а способ работы с ними остался прежним. Поставил Claude Code — дал полный доступ и молишься что не сломает систему. Не дал — натыкиваешь права руками, половина функций не работает. Хочешь нормальную изоляцию — нужны контейнеры или VM, к ним надо подключаться, пробрасывать порты, SSH-сессии, всё это руками.

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

Когда 4 машины, 12 сессий и половина из них — AI-агенты которые что-то пилят в фоне, есть ощущение что что-то пошло не так. Нужна штука которая решает обе проблемы: и изоляцию сред, и визуальное управление всем этим хозяйством — со статусами, переподключением из браузера, и чтобы не надо было жонглировать SSH-сессиями вручную.

В итоге — запилил решение для себя, показал знакомым бойцам — сказали, жги в опенсорс.

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

TLDR;

Использование SaaS в авторизации и аутентификации пользователей для решений не ограниченных контуром предприятия имеют самую большую эффективность и удобство. (можно промотать страницу в самый конец - там будет сравнительная таблица)

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

Написать эту статью меня сподвигнул услышанный недавно краем уха разговор:

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

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

Современный бизнес-аналитик 1С занимается не только сбором требований заказчика и передачей их разработчику. Эта роль стала шире: здесь требуются и навыки проектного управления, и понимание архитектуры решений.

Наталья Китавина, аналитик проектов 1С Ресурсного центра Инфостарта, рассказывает, какими программами сегодня пользуются аналитики и как подобрать инструментальный стек под свои рабочие задачи.

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

Под катом: путь от первого запуска Claude Code до деревни из двенадцати агентов, каждый хак и каждые грабли на этом пути, и неожиданное открытие, что менеджмент AI-команды устроен ровно так же, как менеджмент живых людей.

Я не хочу возвращаться к ручному кодингу.

Но чем больше кода пишут агенты, тем яснее: главная проблема AI-first разработки - и это не качество AI-кода.

Проблема в том, что из профессии исчезает фаза, в которой мы восстанавливались.

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

Техническое решение: Установка камер на уровне лица с углом обзора 120°, обеспечивающих:

Видимость лиц при входе/выходе

Точность до 99.5%+

Сохранение соответствия DPDPA (90 дней хранения для отладки, затем удаление изображений)

Экономическое обоснование (для 56 автобусов):

Стоимость установки: 23.7 млн₽

Дополнительная защита: 12–20 млн₽/год

ROI: 51–84% годовых

Срок окупаемости: 14–23 месяца

Но главное: защита от системных рисков (штрафы, репутация, мошенничество)

Статус: Веду переговоры по интеграции с компанией, которая предоставляет доступ к системам электробусов. Это позволит нам расширить покрытие и снизить затраты на установку.

Айсберг Claude Code: 30+ возможностей от новичка до автоматизации

Привет! Меня зовут Рамиль, я программист отдела серверных решений ЮMoney. Я собрал полезные советы по claude code и организовал её в интерактивном формате «Айсберга». Это способ подачи материала от очевидного к малоизвестному. На верхушке — то, что знает каждый, кто хоть раз открывал Claude Code. Чем глубже — тем реже встречаются эти знания, и тем больше они меняют подход к работе.

Привет, Хабр! Я Максим, ведущий специалист по анализу данных и ML в логистике. Этот пост — про работу с Claude Code: как я выстроил систему, которая не даёт проекту рассыпаться.

Подопытный кролик — мой пет-проект awesome-project.com (название изменено): AI-ассистент для структурированных сессий, React + TypeScript, Express/Node.js, PostgreSQL, DeepSeek. Соло-проект с реальными пользователями, где Claude Code — основной соисполнитель.

За время разработки я собрал полную коллекцию граблей. Проблема была в отсутствии системы работы с инструментом. Теперь есть. Расскажу, как она устроена и что ещё предстоит починить.

В какой-то момент понял, что у меня открыто четыре IDE с разными проектами. В каждой крутится одна или несколько сессий с Claude AI. А я сижу и жонглирую вкладками. Планирование. Ревью там, где критично. Там, где не критично, накидываю хитрые тестовые сценарии, тестируя проект как black box. Постоянно переключаю контекст у себя в голове чтобы понять, а на каком шаге я на этой вкладке и в этом проекте. И потом бам, пора спать. Или есть. Или идти гулять с ребёнком. И в этот момент все процессы останавливаются. Агенты ждут. И получается по факту, что я слабое звено. Не модель с её косяками, а я. Начинаю меньше спать. Парадокс, вроде как должно было быть все наоборот: модели работают, ты спишь. Ан нет.

Или: как корпоративный софт вынудил меня написать своё приложение

Представьте картину. Понедельник, 10:00. В календаре — ежеквартальный all-hands на час. CEO заходит в Teams с видом человека, которому есть что сказать. Первые пять минут — действительно интересно. Потом начинается.

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

Вы смотрите в экран. Потом в окно. Потом снова в экран. Мозг предательски начинает думать о том, что бы поесть на обед и не пора бы поставить кофе.

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

Энцо Феррари начал писать мемуары только после смерти сына Дино. До этого было не до того — гонки, завод, борьба за секунды и победы отнимали всё время. Когда Дино не стало, пришлось остановиться и оглянуться. Так появилась эта книга.

«Мои ужасные радости» — это не хроника автоспорта и не учебник по конструированию болидов. Автор просто делится мыслями, идеями, убеждениями и чувствами, из которых соткана канва его жизни. Строгой хронологии и академической выверенности здесь нет — только живой голос человека, который 60 лет следил за историей гонок из первого ряда и сам же её создавал.

Энцо Феррари — человек, чье имя стало синонимом скорости, страсти и итальянского совершенства. Основатель компании Ferrari, создатель машин-легенд, он прожил жизнь, в которой триумфы и трагедии шли рука об руку. Гонщик, конструктор, руководитель команды — он был всем этим одновременно, но прежде всего он был человеком, одержимым автомобилями.

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

С началом «эры» генеративного ИИ я занимаюсь разработкой агентских систем — и в этой статье хочу поделиться тем, что происходит, когда агента нужно не просто запустить, а сделать так, чтобы он работал надёжно, предсказуемо и без страха отдать его реальным пользователям.

Это будет своего рода дорожная карта подготовки агента к продакшену.

В одной из сессий Claude написал у меня 47 файлов. 1 892 строки. Два новых сценария, рефакторинг шести обработчиков, миграция конфига. 38 минут.

Каждый коммит — автоматический CPG-анализ. Каждый промпт — обогащение контекстом из графа. Каждый пул-реквест — радиус поражения и оценка риска.

Не потому что я не доверяю ИИ. А потому что я не доверяю никакому генератору кода без автоматической верификации. Включая себя.

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

Собрал свой опыт настройки проектов для кодовых агентов. Как написать правила, чтобы агент не делал глупых ошибок, как научить его работать с окружением, как делиться скиллами между репозиториями и не сойти с ума, когда в команде у каждого свой инструмент — Claude Code, Cursor, Copilot.

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

Вот десять трендов, которые определяют разработку с использованием ИИ в 2026 году и что вам с этим делать.

1. Agentic AI: от диалога к автономным действиям

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

Это уже не просто автодополнение кода. Эти агенты понимают контекст репозитория, историю коммитов и архитектурные паттерны. В отчёте Anthropic «Agentic Coding Trends 2026» это называется «интеллект репозитория» — ИИ, который понимает не только строки кода, но и связи и намерения за ними.

Что изменилось с 2025 года: в прошлом году мы говорили о «инструментах разработки с ИИ, выходящих за рамки автодополнения». В 2026 году мы перескочили от расширения возможностей к делегированию. Разработчик уровня 10x может превратиться в 100x — не за счёт написания большего количества кода, а за счёт управления агентами, которые это делают.

Привет, Хабр! Меня зовут Марат Мустафин, я ведущий системный архитектор в «Стрим 1С» группы МТС. Мы поддерживаем и развиваем внутреннюю 1С-экосистему для дочерних компаний, обслуживаем около 1000 пользователей и выпускаем релизы раз в неделю. В этом материале расскажу, как мы выработали подход, сочетающий современные практики DevOps (Development & Operations — разработка и эксплуатация/поддержка) со спецификой платформы, а также поделюсь процессами разработки и нашими ключевыми принципами.

«Стрим 1С» появился в группе МТС в 2021 году как продуктовая команда, которая закрывает автоматизацию ключевых внутренних бизнес-процессов дочерних компаний. У нас работают около 50 специалистов: разработчики, аналитики, архитекторы, QA-инженеры, а также Product Owners и CTO. Функции DevOps в основном закрываем силами архитекторов, но иногда привлекаем профильные команды под конкретные задачи. Формально наш «Стрим 1С» состоит из нескольких команд, отвечающих за свои продукты, но об этом расскажу чуть подробнее дальше.

За время существования «Стрим 1С» мы собрали экосистему, которая обеспечивает:

• еженедельные релизы с высоким уровнем качества, автоматизированный путь от разработки до публикации и надежной инфраструктурой с георезервированием;

• разделение ответственности между продуктовыми командами, отлаженные Agile-процессы с регулярными ретроспективами, а также культуру код-ревью (code review — проверка кода другим разработчиком) и коллективной ответственностью за качество;

современный стек мониторинга и наблюдаемости, комплексное автоматизированное тестирование и инфраструктура как код через Jenkins и Gitlab CI.

В этом нам помогли несколько принципов:

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

• Культура качества. Многоуровневый контроль через код-ревью, автотесты и повторное тестирование помогает держать прод стабильным при высокой скорости изменений.

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

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

В этом материале я покажу, как мы реализуем эти принципы, как встроены в корпоративные процессы и как развили разработку 1С до полноценного направления.