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

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

Четыре года назад технический директор Google заявил, что к 2025 году ИИ обеспечит переход на четырёхдневную рабочую неделю.

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

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

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

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

Другие компании также продвигают идею о том, что ИИ эффективно сократит количество часов, которые людям нужно работать — к лучшему или к худшему. Компания Anthropic похвасталась тем, что её популярный инструмент для программирования и чат‑бот Claude способен работать самостоятельно в течение семи часов без перерыва, что по сути соответствует полному рабочему дню в компании. Марк Цукерберг из Meta заявил, что его компания находится в середине того года, когда «ИИ начинает кардинально менять наш подход к работе», и что такие инструменты позволяют гораздо меньшему числу сотрудников выполнять больше работы — гораздо больше, чем они когда‑либо могли бы сделать раньше.

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

Поэтому эта история будет не только про очередной ИИ-инструмент, но и про команду из 16 человек, которая за несколько месяцев изменила привычный способ работы и перестроилась в пять микроюнитов.

Привет, Хабр! Меня зовут Сергей Чистяков, в ИТ я с 2006 года. Веду канал в телеграм. Сейчас работаю техлидом в Райффайзен Банке и строю систему автоматизации бизнес-процессов, в которой вместе работают люди и агенты. Расскажу про воркшоп, на котором никто не научился писать автотесты, двухдневный дофаминовый шок и пять маленьких команд, которые начали проводить задачи через весь цикл разработки и построили для этого собственный workflow поверх нескольких репозиториев.

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

О том, как меняется подход к автоматизации разработки, рассказали инженеры MTC Web Services на митапе для Go-разработчиков. А еще в эфире разобрали несколько практических сценариев, где в одном случае ИИ-агент получает собственную среду выполнения, в другом типовые инфраструктурные задачи выносятся на общую платформу, а в третьем — код создается на основе описания API.

Общий тренд — разработчику приходится все больше заниматься архитектурой, задавать правила работы и проверять результат. Об этом подробнее под катом.

Пайплайн у вас есть. Он есть у всех: CI перестал быть предметом споров примерно тогда же, когда Docker перестал быть новостью. Именно поэтому разговор пора вести другой - не “зачем вам CI”, а можно ли верить вашему зелёному пайплайну, сколько он стоит и кто им владеет. Разбор в формате “зачем - как - чем - цена отказа” - пилот рубрики: дальше в ней будут другие практики, формат останется.

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

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

Слоган "хватит промптить кодинг-агентов, проектируйте циклы" собрал миллионы просмотров и оброс гайдами "как печатать альфу 24/7". Я полез смотреть, что там под мемом, и за пару месяцев собрал поверх своей обвязки собственный цикл. Переписывал столько раз, что перестал считать.

В кризисный 2026 год многих людей в ИТ увольняют, сокращают, вынуждают уйти. Короче говоря, вслед за просевшей экономикой компании начинают «оптимизации». Кавычки здесь не зря: к речекрякам, которые якобы должны залакировать негативную часть действительности, у меня плохое отношение.

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

Я на своём опыте пережил 5 увольнений, хороших и плохих. Как руководитель, я увольнял сотрудников. За 16 лет в отрасли я видел много примеров, когда другие руководители не справлялись с уровнем стресса в течение этого процесса и начинали делать вещи, за которые потом они наверняка испытывали чувство стыда.

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

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

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

Стратегическое управление правами на интеллектуальную собственность, направленное на защиту собственных R&D инвестиций компании и минимизацию рисков, связанных с нарушением интеллектуальных прав третьих лиц, требует несколько более комплексного подхода, чем реализация частных мер по анализу патентной чистоты. Так, Nippon Steel, неоднократно удостоенная награды Thomson Reuters Top 100 Global Innovator Award, присваиваемой по совокупной оценке ряда количественных и качественных характеристик патентного портфеля, рассматривает стратегию в отношении интеллектуальной собственности как одну из трех ключевых стратегий компании, на одном уровне с бизнес-стратегией и R&D стратегией.

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

Почему одни идеи превращаются в востребованные продукты, а другие так и остаются красивыми презентациями — или мемами про очередной B2B AI SaaS? Часто проблема не в технологии и не в качестве реализации. Команда может отлично сделать то, что пользователю на самом деле не нужно.

В IT легко начать с готового ответа: «сделаем экспорт», «добавим ещё один экран», «автоматизируем этот сценарий». Дизайн-мышление предлагает на время отложить решение и сначала разобраться, какую проблему мы вообще пытаемся решить.

Меня зовут Лера, я технический писатель в Авито. Я продолжаю разбирать книги, идеи из которых помогают по-новому посмотреть на работу, команды и создание продуктов. Сегодня поговорим о книге Тима Брауна «Дизайн-мышление в бизнесе».

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

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

Привет, Хаброжители! «Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему». Этот принцип, сформулированный в «Анне Карениной», применим не только к семьям, но и к командам, работающим над легаси-системами. Разные программные системы страдают от разных болезней, которые требуют разных методов лечения. В последние годы — в монолитах, микросервисах и в их организациях — наблюдаются во всевозможных комбинациях следующие проблемы.

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

Open source компонент редко остается неизменным после того, как попадает в большой продукт. Если команде не хватает нужной функции, библиотека плохо стыкуется с внутренней системой или выпуск обновления безопасности не укладывается в запланированные сроки, то в ход идет доработка собственными силами. Часть изменений в таком случае отправляется в исходный репозиторий, тогда как остальные годами живут в отдельной ветке.

В конце 2025 года Linux Foundation Research опросила 567 специалистов о том, как их организации работают с такими изменениями. Результаты вошли в февральский отчет «ROI for Open Source Software Contribution». Формально исследование посвящено финансовой выгоде от вложений в open source, но нас в отчете больше всего заинтересовала практическая часть. По таблицам из отчета можно понять, что именно компании дорабатывают, когда отправляют код авторам проекта и в каких случаях сохраняют собственный форк.

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

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

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

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

Можно ли сделать e2e тесты мощным инструментом раннего отлова багов, не потопив при этом CI и не всем не разругавшись?

Рассказываю, через что пришлось пройти, чтобы релизы были спокойные, пайплайны — зеленые, разработчики — довольные.

Как мы это внедряли, сколько сопротивления получили и что из этого выжило спустя четыре месяца.

SOLID в реальном мире: LSP без квадратов и прямоугольников Дисклеймер: статья для разработчиков уровня junior и middle, которые знакомятся с принципами чистого кода и SOLID. Примеры кода — PHP 8.1+.

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

Новость о том, что Anthropic объявила о внесении во все тексты водяного знака, слышали и обсудили уже все. С 2 августа во все тексты, которые пишет Claude, встраивается невидимая метка, и она не на уровне невидимых символов, что легко удаляются через сторонний редактор, или метаданных рядом с файлом. Это статистический сигнал внутри самих слов. И подобное переживает копирование, вставку и даже часть редактуры. Убить такое можно только через серьёзный рерайт.

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

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

Спойлер: нет, я не про пандемию

Всем привет! На связи Саша Петрушин, я руковожу группой разработки в центре разработки и машинного обучения компании «Инфосистемы Джет».

Недавно я нашёл старый черновик статьи, которую так и не опубликовал с 2020 года — про фронт личного кабинета крупного портала. Перечитал и вспомнил, насколько это было круто и адово.

Дисклеймер: в этой статье – теория, как проект мог измениться в 2026 году. ИИ-агенты — это другие требования к информационной безопасности. Используйте их разумно.

В марте, в разгар локдауна, я пришёл в команду пятым разработчиком: Angular 1.4 с Backbone, переписывание на React, виджеты, 2400+ сценариев подачи заявлений. Потом мы расширили команду до двадцати фронтендеров.

В общем, поностальгировал по команде и ощущению «мы же это реально сделали».

А после задался двумя вопросами.

Как бы я решал ту же задачу сейчас?

И что вообще изменилось в реальной экономике поставки продукта за последние пять с лишним лет?