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

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

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

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

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

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

Я Ирина, в Блоке ИТ-развития инвестиционного бизнеса РСХБ.Цифра помогаю ИТ-командам доставлять ценность бизнесу, содействую оптимизации процессов, повышению эффективности и сплоченности команд, продвигаю Agile-практики.

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

Говорят: “выстраивать процессы”. А откуда они берутся, как это обычно происходит, и вообще, зачем это всё?

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

Процесс никогда не должен быть самоцелью. И нет никакого универсального процесса на все случаи жизни.

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

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

Недавно я задался вопросом: можно ли организовать полноценный agent dev loop (то есть, цикл разработки агентов), используя только локальные модели? Идея заманчивая — гонять агента по задачам бесконечно, не оглядываясь на счета от OpenAI или Anthropic и не переживая за утечку кода.

Чтобы проверить это, я выделил кластер и столкнул лбами три тяжеловеса из мира open source. Спойлер: архитектурно они все — Senior-разработчики, но когда дело доходит до docker-compose up, начинаются проблемы.

Выбирая LLM для своего первого пет-проекта, я случайно создал бенчмарк для LLM "Испытание Дали" по трем параметрам: качество, скорость и стоимость. Этот бенчмарк позволил мне найти оптимальную LLM для встраивания в продукты моей компании Флаг Софт. Возможно, вас тоже заинтересуют его результаты.

Когда ко мне обратился клиент, он сформулировал проблему примерно так: «Вся информация есть, но связана только у меня в голове».

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

К весне 2026 года Claude Code уже вышел на run‑rate выручки свыше $2,5 млрд, а Codex используют более 4 млн разработчиков в неделю. Ещё год назад такие цифры казались бы фантастикой для инструментов вокруг кода. Теперь это новая реальность: владельцы ведущих моделей больше не ограничиваются API и исследованиями — они сами заходят в терминал, IDE и корпоративный контур разработки.

На этом фоне особенно интересно, что происходит с Cursor. Ещё в 2023–2024 годах он выглядел почти идеальным ответом на вопрос, как должна выглядеть современная разработка с ИИ. Не чат сбоку, не набор автодополнений поверх редактора, а полноценная среда, которая понимает кодовую базу, держит контекст и помогает программировать эффективнее. Но к весне 2026 года вопрос звучит уже иначе. Не хорош ли Cursor, а остался ли вообще смысл в отдельном платном ИИ‑редакторе, если создатели ведущих моделей пришли в этот слой напрямую.

Именно поэтому главный вопрос для Cursor сегодня не в том, «умрёт ли компания». С компанией как раз всё неплохо: по данным Bloomberg, годовой темп выручки Cursor превысил $2 млрд. Вопрос в другом: не исчезает ли сама логика, при которой отдельный ИИ‑редактор является обязательной прослойкой между разработчиком и ведущими моделями.

Про Developer Experience любят говорить, проводя параллели со счастьем. Счастливый разработчик пишет хороший код, остаётся в компании, приводит друзей. Звучит хорошо, продаётся хорошо. Только когда я спрашиваю на интервью «а сколько это счастье стоит и что оно приносит бизнесу», в ответ обычно начинается мычание. Потому что счастье — это маркетинговая обёртка, в которую упаковали DX, чтобы продать его людям с бюджетами. Обёртка свою работу сделала, про DX начали говорить. Но если вы строите стратегию вокруг счастья, то вы почему-то начинаете покупать в офис кресла и фрукты, а пайплайн как собирался 40 минут, так и собирается.

Замечаю, что часто люди подстраиваются под инструменты для работы, а не наоборот

Подумаем в статье почему так происходит и что с этим делать

В первой статье я писал про SDD на примере одного вечера. После чего прошёл 17 спринтов SDD на FullStack‑приложении: B2C‑трекер привычек и целей, два репозитория, 251 тест на бэке и 77 на фронте, релиз в продакшен. Здесь — что не дало мне потерять контроль на этом масштабе.

Если вы часто упираетесь в лимиты Claude Code / Codex и не понимаете, куда улетают токены — этот лонгрид для вас

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

Разбираемся

1. Как устроено контекстное окно изнутри: 7 слоёв (от весов модели до MCP и skills)
2. Что такое attention и при чем тут O(n²)
3. Как работает agent loop на примере 4 вызовов модели
4. Почему prompt caching экономит до 10× в лимитах при правильной работе с ним

Сууупер длинная статья

Этот документ описывает процедуру воспоминания о девушке по имени Аня, с которой пользователь встречался в период с февраля 2011 по декабрь 2024 года. Процедура предназначена для случаев, когда автоматический триггер (запах кофе в кофейне White Swift, песня Animal Jazz “Три полоски на кедах”, фотография красных песков Алтая ближе к монгольской границе) приводит к непредвиденному состоянию системы.

Версия: 2.4.1
Последнее обновление: четверг, в три часа ночи
Статус: deprecated, но не удаляется.

1. Предварительные требования
Перед запуском процедуры убедитесь, что выполнены следующие условия:
* Вы один в комнате
* Уровень освещённости — низкий (рекомендуется настольная лампа с тёплым светом, не верхний свет)
* Все мессенджеры закрыты (особенно Telegram — известный источник побочных эффектов)
* В радиусе досягаемости находится: стакан воды, плед, Chateau Mukhrani Reserve Royale Goruli Mitsvane (опционально, но настоятельно рекомендуется)

⚠️ Внимание: запуск процедуры в состоянии алкогольного опьянения приводит к рекурсивному вызову функции написать_бывшей(), которая, как известно, не имеет корректного выхода.

2. Инициализация
2.1. Загрузка контекста
Откройте папку ~/память/2025/. Внутри обнаружится подпапка аня/. Не открывайте её сразу — сначала выполните:
$ ls -la ~/память/2025/аня/

Вы увидите 247 файлов. Большинство из них — .jpg, несколько .mp3 (в основном — голосовые сообщения), один файл последний_разговор.txt размером 4.2 КБ.

2.2. Проверка целостности
Файл последний_разговор.txt за прошедшие годы мог быть повреждён в результате многократного перечитывания. Это нормально. Не пытайтесь его восстановить — оригинал утерян безвозвратно, а ваша текущая версия содержит правки, внесённые задним числом, на основе того, как должно было быть.

Третья неделя в новой компании. меня спрашивают кто в соседней команде отвечает за конфиги админки и где лежит контракт по realtime-интеграции с витринами партнёров. отвечаю без открытия браузера.

Я ж не гений. просто всё это уже в одном каталоге и достаётся одной командой в терминале.

Сколько людей - столько и мнений о процессах в команде (с). 

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

За отправную точку возьмем несколько потребностей: 

• управлять неопределённостью,

• повышать качество требований,

• снижать риски на этапе разработки. 

Поделимся опытом работы в команде разработки продукта электронного документооборота. 

Расскажем о своих решениях, ошибках, находках, и компромиссах и о рабочей модели, которой мы сейчас придерживаемся.

Как превратить десятки неструктурированных описаний участников сообщества в систему поиска

«Занимаюсь бэкендом лет 7, Go и Python, немного ML» — попробуйте найти среди двухсот таких описаний нужного человека. Руками — часы. Я автоматизировал это через гибрид LLM + детерминированного кода, и отловил все возможные проблемы.

Рассказываю про архитектуру, промпты и решения.

* На обложке — Архимболдо «Библиотекарь» (1566): из разрозненных книг складывается цельный образ. Как и профиль участника в системе

Некоторое время назад я высказал предположение, что проблемы С++ настолько глубоки, а процесс принятия решений комитетом настолько медленный, что доработки в С++ не в состоянии успеть за скоростью развития отрасти Ахиллесова пята C++ и будущая р̶е̶ эволюция / Хабр.

Конечно, я не считаю, что С++ будет забыт, но с большой долей вероятности ему будет уготована нишевая роль, как сейчас это произошло с языком С, которому С++ и пришел на замену. Причем я предположил, что способ плавной замены С++ на какую то альтернативу должен происходить точно также, как сам С++ пришел на замены старому С, через транспрлайтер (sourse to source translation).

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

«Самые трудные уроки, которые я усвоил, — не о том, как работаешь ты сам, а о том, как работают команды: как на самом деле принимаются решения, где ломается координация, чем отличаются команды, которые доводят дело до конца, от тех, кто стоит на месте. Этот список советов про то, как стать сильнее как отдельный инженер, и больше — про системы вокруг инженерии.» — Эдди Османи, ирландский инженер‑программист, директор в подразделении Google Cloud AI.

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

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