Устав и летопись кодинг-агентов

При ИИ-ассистированной разработке (или, если угодно, вайб-кодинге) довольно быстро проявляются одни и те же проблемы:

  • деградация контекста (модель “забывает” детали);

  • саботаж команд или неаккуратное следование;

  • трудности переноса контекста (в новую сессию или агента);

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

  • малая наглядность и проверяемость процесса разработки.

(далее…)

Десятки деплоев в день — и ни одного подвига

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

Типичный день в нашем CI выглядит так: десятки зелёных галочек подряд, тесты проходят за 20-30 секунд, деплой в прод занимает одну-две минуты, изменения катят несколько человек за день. И это лишь один репозиторий из десятков активных.

(далее…)

Как мы строили ВКС в корпоративном мессенджере: от WebRTC до вебинаров, SIP и ИИ

Подключиться к созвону сегодня так же просто, как отправить сообщение в корпоративном мессенджере. Один клик — и конференция готова. Но что творится под капотом платформы коммуникаций, когда вы нажимаете кнопку “Создать встречу”?

(далее…)

Сравнение Codex, Claude Code и Kimi. Кто лучше на практических задачах

Сравнение Codex, Claude Code и Kimi. Кто лучше на практических задачах

Меня зовут Илья, я разработчик и пишу про разработку приложений. Сегодня расскажу про эксперимент, который я решил провести после выхода очередной модели, которая превышала по бенчмаркам другие. Показатели каждой новой версии моделей стабильно превышают предыдущие, но при этом они не отвечают на вопрос: какой cli агент лучше использовать при разработке. Я решил попробовать сравнить три агента Codex, Claude Code и Kimi на одной реальной задаче в одинаковых стартовых условиях, чтобы посмотреть чем реально отличаются результаты их работы.

Что на входе

(далее…)

Эффект «сломанного телефона» в цепочке поставки

Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

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

(далее…)

Как мы делаем беспилотные тракторы без кабины: рассказ главного конструктора Когнитив

Сотни миллионов долларов убытков, пиар-катастрофа и травма Андрея Дороничева: вспоминаем провал Google Stadia

На днях посмотрел интервью с Андреем Дороничевым. На 58-й минуте он вспоминает о своей работе над Stadia: заметно, как больно ему об этом говорить; видно, что он вложил в проект всю душу, а после его провала испытал настолько глубокое разочарование, что ушел из Google. Может, конечно, я ошибаюсь, но это ощущается как настоящая личная трагедия, а не обыкновенный невзлетевший стартап, после закрытия которого можно на следующий же день запускать новый бизнес.

(далее…)

Единые цели — разные бэклоги: практический подход к синхронизации команд

Введение

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

Что произойдёт, если команды в конце цепочки не знают о планах владельца core-продукта? Что будет, если инициативный Product Manager сможет быстро провести свой бэклог через смежные команды, но локальная оптимизация приведёт к общим потерям и замедлению time to market? Кто отвечает за задачи, которые годами накапливаются между командами?

(далее…)

ИИ‑агенту недостаточно правил: как мы передаём ему инженерный опыт

Сначала нам советовали подробно задавать правила в промпте. Промпты росли и постепенно превращались в:

Ты опытный программист. Пиши хороший код. Плохой код не пиши.

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

(далее…)

Убрали Story points и бизнес ослеп. Прозрачность доставки без театра оценок

Под моей прошлой статьёй (про Scrum, который натягивают на всё подряд) читатель описал ситуацию, от которой у меня знакомо заныло под ложечкой. Пересказываю по памяти и анонимно: «У нас под предлогом адаптации отвалились оценки и демо. Команда называет это гибкостью. И теперь нечем показать бизнесу, что разработка вообще работает».

Если убрать эмоции, это самый частый вопрос, который я слышу после «какой фреймворк выбрать»: чем доказывать, что разработка работает, когда привычную витрину (оценки, графики сгорания, демо) разобрали? (далее…)