Дайджест публикаций за июль 2026 г.

Head of Development управляет отделом разработки: несколькими командами, процессами, наймом и стратегией — связующее звено между Engineering Manager'ами и CTO.

Engineering Manager отвечает за людей в команде разработки: найм, развитие, performance review и процессы — при сохранении технической экспертизы для понимания команды.

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

Бизнес-аналитик переводит язык бизнеса на язык разработки: исследует процессы, формулирует требования и следит, чтобы команда сделала именно то, что нужно заказчику.

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

Функциональная команда: специалисты сгруппированы по специализации (отдельные отделы бекенда, фронтенда, QA) — устройство, управление, требования и границы применимости.

Современные модели IT-команд: Team Topologies (stream-aligned, platform, enabling, complicated-subsystem) и Spotify Model (squad, tribe, chapter, guild) — устройство, управление и когда подходят.

Проектная команда (task force): временная кросс-функциональная команда под конкретную цель с одинарным подчинением — устройство, управление, требования и когда подходит.

Продуктовая команда: кросс-функциональная stream-aligned команда, владеющая продуктом end-to-end (feature team, two-pizza team) — устройство, управление, требования и когда подходит.

Матричная структура: сотрудник постоянно подчиняется двум руководителям — функциональному и проектному (solid line и dotted line). Разбор модели и её отличия от проектной команды.

Бенчмарки LLM — как устроены стандартизированные тесты моделей, что скрывается за цифрами в лидербордах и каким результатам можно доверять.

Метрики LLM — как системно оценивать качество моделей, контролировать деградацию и принимать решения о выборе, доработке и эксплуатации.

Серверный OpenCode, отдельная модель на ревью и собственный агент для инфраструктуры — как я развёл LLM по ролям.

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

AIDD — как превратить хаотичный «кодинг с AI» в дисциплинированный процесс, где AI генерирует код, а человек отвечает за спецификации, архитектуру и валидацию результата.

DDD — это не про паттерны кода, а про модель: домен и единый язык (ubiquitous language) управляют дизайном так, что код становится читаемой проекцией бизнеса, а расхождение модели и реализации — источником дефектов, который нужно устранять непрерывно.

Type Driven Development — это когда компилятор работает доказательством корректности: если код компилируется, он правильный.

TDD — это не про тесты, а про дизайн: короткий цикл «красный → зелёный → рефакторинг», в котором тест, написанный первым, заставляет код быть тестируемым, а значит — слабосвязанным и понятным.

BDD — это не про тесты, а про общий язык: сценарии «Given-When-Then» рождаются в диалоге бизнеса и разработки, уточняют требования и затем исполняются как живая спецификация.