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

Полезная внутренняя функция редко остаётся функцией без зависимостей. Сегодня ей понадобился python-dateutil, завтра — конкретная версия NumPy. Когда тот же код нужен во втором проекте, приходится либо менять его lockfile, либо собирать отдельный контейнер, либо превращать десять строк в сервис.

splime предлагает ещё один вариант: опубликовать доверенную Python-функцию вместе с точными версиями пакетов и вызывать её по имени. Локальный демон сам собирает окружение и хранит его отдельно от проекта, который будет вызывать функцию. Общая модель была в первой статье, а упаковка функции — в предыдущей части. Этот текст можно читать отдельно.

Сначала запустим функцию, чья зависимость вообще не установлена у вызывающего кода. Затем посмотрим, откуда берётся venv, почему он кэшируется и когда одной ноде стоит назначить native, venv-subprocess или Docker. Материал рассчитан на macOS и Linux с Python 3.13+; в splime 0.4.9 сборка локальных окружений требует POSIX.

Площадки перестали пускать машинный текст самотёком. Habr проверяет публикации автоматически, а Кевин Индиг пишет о том, что платформы строят anti-slop-системы — механизмы подавления массового низкокачественного ИИ-контента. Дальше обычно следует совет писать хорошо, и на этом разговор заканчивается.

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

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

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

Мы поговорили с тремя командами, которые используют продукты из экосистемы Инфостарт Маркетплейс в повседневной работе:

Всем привет!

Почти каждый, кто работал с Git больше пары недель, хоть раз сталкивался с одной и той же путаницей: почему git add — это не сохранение, зачем нужен какой‑то отдельный индекс, если есть коммит, откуда вообще берутся конфликты при мерже, если мы просто оба поправили один файл. И почему иногда git status показывает файл как изменённый, хотя вы точно ничего не трогали.

Если вы так же знакомы с этими проблемами, а также с другими проблемами при работе с Git — эта статья для вас.

В этой статье cначала покажем, как Git на самом деле хранит файлы и их изменения, что такое индекс и почему он существует отдельно от рабочей директории и коммитов. Далее — как устроены ветки на уровне данных, а не только как указатель текущей линии разработки. После этого разберём, как Git определяет, какие именно строки поменялись, и как из этого механизма следует слияние т.е merge и, самое главное, конфликты при слиянии.

Изучив модель, пройдёмся по основным командам работы с файлами: add, rm, mv, restore, diff, log, stash, работу с .gitignore и с большими файлами.

А в конце мы вам покажем, как это всё применяется на практике.

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

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

Если начинающие программисты передают AI написание кода, поиск ошибок и принятие технических решений, возникает неудобный вопрос: откуда через пять лет возьмутся senior-разработчики, способные проверять AI-generated code и отвечать за него в production?

Компания выбирает не только преимущества решения. Она одновременно выбирает его цену, ограничения и будущие проблемы.

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

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

Личная история о том, как двадцатилетняя мечта о математически доказуемом коде неожиданно стала ответом на главный вызов эпохи ИИ-агентов.

13 сентября ИТ‑сообщество празднует День программиста, и это хороший повод вспомнить, какими разными бывают люди, которые создают технологии. За каждым успешным продуктом стоят архитекторы, DevOps‑инженеры, дизайнеры, продакты и другие специалисты. Если присмотреться к их рабочим привычкам, можно найти повторяющиеся паттерны: одним важна системность, другим — командная игра, третьим — визионерство.

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

Добро пожаловать обратно, друзья. Если вы читали первую часть, то знаете, как мы выстраивали периметр, прикрывали тылы и готовились к штурму. Теперь переходим к самому интересному — к продукту. К тому самому «цифровому космолету», который должен был перевернуть рынок пассажирских перевозок.

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

В этой части я проведу вас через наш интеграционный лабиринт. Расскажу, как мы собирали команду, выстраивали процессы, договаривались со стороной интегратора и проектировали идеальное API. Какой путь мы успели пробежать за 8 месяцев хардкора. И как я впервые столкнулся с «обстоятельствами непреодолимой силы». В финале я дам вам 10 правил работы с госами, которые мы вынесли из этого опыта и могут оказаться полезными, если вы окажетесь в подобной ситуации.

Если вы не читали первую часть — рекомендую вернуться. Там о том, как мы выстраивали юридическую защиту и внедряли практически полноценный Agile под маской Waterfall. Это не просто «история», это набор инструментов, который помогал нам не сойти с ума. Но если вам ближе продуктовое мясо и детали реализации — добро пожаловать прямо сюда. Читать мою историю можно в любом порядке.

Приготовьтесь, отправляемся. Следующая станция — «прод».

Одна из самых дорогих встреч в нашем календаре выглядела совершенно обычно. Раз в неделю 20-25 человек собирались на 1,5 часа, чтобы оценить задачи. Раз за разом встреча повторялась, забирая время разработчиков и техлидов, а результат строился на уже известной команде информации: описаниях задач, истории похожих работ и прошлых оценках.

Мы отдали эту работу агенту, которого назвали Эстима. Через 1,5 месяца пилота сходимость его оценки с ручной достигла 95%. После этого встречу отменили, валидацию оставили техлидам и получили экономию около 20 человеко-дней в месяц.

Именно Эстима помогла команде поверить в практическую ценность AI. За ней появились агенты для работы с Jira, ревью кода, разработки, тестирования, аналитики и AppSec. Вместе они постепенно изменили наш PDLC.

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

Профессия разработчика не исчезнет. Но замена уже началась в менее кинематографичном смысле. Один человек с агентами забирает объём работы маленькой команды, а рынок перестаёт платить за медленное ручное исполнение.

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

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

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

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

Поэтому вопрос «заменит ли AI разработчиков» для меня закрыт. Он не отменит профессию. Он изменит объём результата, который рынок ожидает от одного человека. Тот, кто не перестроится, формально останется разработчиком, но перестанет держать уровень.

Агент сам себе поставил PASS. И я это проглотил.

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

В статье собираю гейт, после которого работа не идёт дальше, пока другой агент не написал вердикт в отдельный файл. В одном чате, без оркестратора, за вечер. Цена — 2,7× обращений к модели, ловит примерно каждую шестую работу.

Готового файла роли не даю: он настроен под мои сбои и у вас не сработает. Даю промпты, которыми агент заведёт вам ваши правила, и после каждого строку «что проверяете в ответе».

P.S. Первый же прогон проверяющего отклонил мою работу. Я был зол. Потом открыл его файл вердикта и понял, что он прав.

Я довольно активно использую ИИ в разработке примерно с конца 2024 года.

Наверное, многие слышали оценки в духе: «ИИ ускоряет разработчика на 20–30%». Возможно, для каких‑то привычных задач это и неплохая метрика.

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

За один очень плотный рабочий день — примерно 11 часов от идеи до боевого переключения — удалось исследовать закрытый Windows‑компонент, восстановить недокументированный бинарный протокол, разобраться с особенностями криптографии, написать совместимую реализацию на Java, сформировать регрессионный корпус из реального трафика, завернуть всё в контейнер, развернуть в Kubernetes, провести независимое ревью и переключить production.

И вот после такого слова про «+30% производительности» начинают казаться немного смешными.

Честно говоря, это пока самый впечатляющий кейс разработки с AI, который у меня был. Восторг скрывать не буду:)

В комментариях к прошлой статье сформулировали правило, под которым я подписываюсь обеими руками: “платить” за внепроцессный вызов имеет смысл тогда, когда сама работа дороже транспорта. clean_amount из квикстарта — десять строк, ноль зависимостей, микросекунды работы — этот порог не проходит. Свою задачу тот пример выполнил: показал механику publish/call в шесть строк. Но ноды существуют не для него: 2 + 2 через демон не нужно никому, и splime строился не для этого.

Возьмём случай, где оверхед оправдан, залезем под капот и посмотрим, что происходит между publish и call: где физически живёт нода, как Python-функция превращается в переносимый объект и как две ноды передают друг другу данные, которым не место в JSON.

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

Всё, что ниже, проверено на актуальной splime 0.4.9.

Девять месяцев назад я начал запускать таймер каждый раз, когда сажусь за конкретную задачу. За это время одна категория “студия” превратилась в систему проектов, ролей и описаний, а тайм-трекинг стал способом оценивать работу не по ощущениям. Рассказываю, как я веду Toggl Track, почему отдельно считаю управление, разработку и созвоны, что помогает не забывать про таймер

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

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

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

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

Почему без интеграции ИТ‑систем все усилия по цифровизации умножаются на ноль.

В статье разберём четыре подхода, которые компании выбирают, когда доходит до интеграций ИТ‑систем: классические «точка‑точка» (они же «спагетти‑код»), брокеры сообщений вроде Kafka и RabbitMQ, Open Source‑решения и готовые ESB‑платформы. Посмотрим на примерах, как каждый из них работает в бою, какие грабли ждут на каждом пути, и почему «бесплатно» на входе часто оборачивается очень дорогим сопровождением.

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

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

Нам передали уже работающий сервис голосовых ИИ‑интервью со словами: «Надо только дотащить до прода». Внутри не было логирования, метрик и воспроизводимых тестов. Рассказываю, как работа с задержками и детектором голосовой активности постепенно превратила готовое демо в инженерный продукт.