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

Команда разработчиков под руководством Андрея Бреслава, российского разработчика и автора языка программирования Kotlin, представила публичную альфа-версию нового инструмента для разработчиков — CodeSpeak. Платформа позиционируется как язык программирования нового поколения, в котором инженеры пишут спецификации на английском языке, а нейросети берут на себя генерацию, тестирование и рефакторинг исполняемого кода. Полноценное внедрение инструмента позволяет сократить объем кодовой базы в проектах в пять-десять раз. Технология поддерживает интеграцию в существующие сложные проекты на Python.

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

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

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

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

На одном из недавних мероприятий эксперты из Сбера, Яндекса и red_mad_robot обсуждали внедрение ИИ в жизненный цикл разработки продукта — AI PDLC. В выступлениях снова и снова звучала одна и та же мысль: роль разработчика меняется. Всё чаще он не пишет код вручную, а формулирует задачу для ИИ, проверяет результат, удерживает архитектурный замысел и задаёт рамки.

Если выстроить эту дискуссию в логике «от стратегии к человеку, от человека — к производственной практике, а затем — к рыночным кейсам», картина становится особенно ясной. Сначала — взгляд Сбера на зрелость AI‑driven разработки. Затем — разбор того, что этот сдвиг делает с людьми. После этого — разговор о том, что действительно работает в корпоративной среде. И уже потом — внешние кейсы Яндекса и red_mad_robot, на которых видно, как меняется повседневная инженерная работа и экономика выпуска продукта.

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

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

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

И именно здесь ломается наивный human-in-the-loop, а большой diff - является лишь симптомом. Настоящее узкое место - стоимость повторного входа в контекст: формально человек остаётся в процессе, но фактически его роль всё чаще сводится к механическому одобрению, в свою очередь дефицитом становится не машинная производительность, а человеческое внимание.

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

Но однажды «оно» падает.

Если вы тимлид или техдир, ваше утро редко начинается с неспешного наслаждения чашкой кофе. Скорее, оно начинается с открытия пяти разных вкладок.
Картина знакомая и удручающая: бэклог продукта живёт в одной системе (которую либо давно не обновляли, либо вообще собрали из того, что было), код лежит в GitLab, саппорт отбивается от пользователей и заводит баги в каком-то отдельном ServiceDesk, а сборка релизов, планирование ресурсов и метрики трекаются… да-да, в «любимом» Excel или Google Таблицах.

Всем привет! Сегодня я хочу поделиться опытом создания веб-приложения на основе GigaChat API от Сбера. В проекте я использовал не только текстовый диалог с нейросетью, но и добавил голосовой ввод (распознавание речи) и озвучку ответов с помощью SaluteSpeech. Получился полноценный голосовой AI-ассистент. В этой статье я расскажу о технических деталях: как получить доступ к API, как организовать обмен сообщениями, кэшировать токены, обрабатывать ошибки и сделать удобный интерфейс.

Проблема: когда коммуникации поглощают рабочее время

Исследование: сколько времени уходит на коммуникации?

Практика: три разных мира коммуникаций

Размер имеет значение

План действий: как вернуть время для работы

Как измерить успех?

Обратная сторона медали: когда нельзя сокращать коммуникации

Краткий вывод

Cтарший инженер-программист в организации JavaScript Infrastructure & Terminal Experience компании Bloomberg Джейсон Уильямс опубликовал пост, в котором рассказал, как он вместе с командой реализовывал библиотеку Temporal вместо Date для различных типов дат и времени. Автор выступает делегатом TC39 (группы экспертов из Ecma International, отвечающей за стандартизацию и развитие языка JavaScript) и имеет опыт стандартизации функций, реализации языка и участия в крупных проектах с открытым исходным кодом. Джейсон также является создателем движка Boa JavaScript.

4 месяца, 1 700 коммитов, 3 880 тестов, 94.83% покрытие — и ни одной строчки кода написанной руками. Как я построил production-приложение на Elixir/Phoenix силами Claude Code: архитектура процесса, TDD, два production-инцидента и уроки.

«Эти архитекторы делают непонятно для кого», «Я тут в Miro накидал», «Нарисуй там что-нибудь архитектурное, а то мы уже код пишем» – знакомо?

Привет! Меня зовут Ущаповский Антон, я архитектор решений в МВС ИИ, последние несколько лет активно погружаюсь в различные аспекты разработки ПО и в ИТ-архитектуру, в частности. Как следствие, накопилось некоторое количество повторяющихся «болей», которые встречаю из раза в раз и наблюдаю их на регулярной основе практически на каждом ИТ-продукте.

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

Что происходит с инженерной практикой, когда код в проекте пишет не человек, а агент, а команда занимается средой, ограничениями и контурами проверки? В этом тексте — разбор реального эксперимента OpenAI, где внутренний продукт собирали через Codex почти без ручного кода: с собственными правилами для агентов, архитектурными инвариантами, наблюдаемостью, документацией внутри репозитория и постепенным ростом автономности. Это любопытный взгляд на разработку в режиме, где главным дефицитом становится уже не скорость написания кода, а человеческое внимание.

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

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

Статья основана на личном шестимесячном опыте автора по внедрению Cursor в процессы разработки моделей, сервисов и MLOps-процессов. Делается вывод, что роль разработчика смещается от написания кода к постановке задач, проектированию архитектуры и контролю качества, при этом ИИ берёт на себя реализацию и рутинные операции.

Тимлиды и команды в больших компаниях постоянно сталкиваются с одной и той же проблемой: бизнес хочет знать сроки, а разработка не может их назвать. Оценки «пальцем в потолок», спринты без delivery, злые заказчики и выгоревшие разработчики — знакомо?

«Три карандаша» — это метод инженерного груминга, который я разработал в боевых условиях и который сейчас стал частью стандарта разработки в Газпромбанке. Суть простая: вы берете доску, три цветных маркера и за два часа превращаете размытые бизнес-требования в понятный план работ с реалистичными сроками. Он подходит для любых задач: фронтенд, бэкенд, data science, интеграции. Если вы можете разложить работу на логические шаги — вы можете использовать три карандаша.

Всем привет. Меня зовут Рустам Файзулин. 30 лет BE- и data-science-разработчик, последние семь лет работаю коучем в Газпромбанке. Моя задача — сделать так, чтобы разработчики понимали, что надо сделать, а бизнес понимал, когда он это получит. Дальше расскажу, как родился мой метод, как он устроен и как внедрить его у себя.

Вчера выкатили 3 релиза, а сегодня поддержка ловит очередной инцидент, но уже непонятно, какой именно релиз его вызвал. Знакомая картина?

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

Привет, меня зовут Артем Герасимов, я владелец продукта SimpleOne SDLC. В этой статье я расскажу вам, как слишком частые релизы могут негативно сказываться на качестве продукта и что с этим можно сделать.

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

В последние несколько лет в финтех-компаниях всё чаще появляется новая роль — BISO (Business Information Security Officer).

Когда я с этим столкнулся, я подумал только об одном: «Это просто новое модное название безопасника или всё-таки отдельная профессия?»

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

Причём особенно активно она появляется именно в финтехе.

Чтобы понять почему, нужно сначала посмотреть на то, как вообще устроена безопасность в технологических компаниях.

Почему классическая модель безопасности перестала работать

Исорически информационная безопасность в компаниях строилась довольно централизованно.

Обычно структура выглядела примерно так:

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

Начнем с того, что большинство проблем при внедрении DevOps происходят не из-за сбоев в работе инструментов. То есть, они происходят из-за неправильных методов, коротких путей и неверных решений, выбранных при внедрении процессов DevOps.