Пока мир сходит немного с ума с нейронками по паспорту и опенсорс суверенными моделями, я решил начать читать настоящую базу - книгу Эванса по DDD. По ощущениям я снова оказался в той ситуации, где мне нужно разъяснение, а как код то писать надо. Первый раз меня подтолкнула книга "Чистая архитектура", где я понял, зачем интерфейсы вообще нужны. Пока что, прочитав 1 главу, которая посвящена тому, как говорить заказчиком про ТЗ, буквально. Мне этой проблемы не понять, может ранее программисты напрямую общались с заказчиком, а не через менеджеров, и им реально приходилось вытаскивать адекватные требования из людей. Да и не понял я момента, где он говорит, что должен быть поток обратной информации от разработчика. Однако довольно интересный момент в 1 главе есть. А именно замечание о том, что какие-либо правила системы не надо прятать в операциях, а надо выносить на уровень хотя бы методов. И делать это надо не ради расширяемости или чего-то еще, а что бы просто ментально было понятно, что тут не просто домножение на10 или деление на 3, а специальная операция для определенной цели.

От подписчика: Отчет Faros.ai про реальные цифры продуктивности разработки с ИИ. Ну... Не все так однозначно... Это реальные метрики кода от требований до доставки. Выборка – 4000 команд за 2 года, сравнение внутри одних и тех же компаний между кварталом минимального и максимального использования AI. Главные цифры: – Продуктивность отдельного разработчика выросла, но скромно, судя по merge requests. Примерно +16 процентов, а не 10x – При этом скорость доставки релизов упала на 11 процентов. Это системная метрика, она про доставку ценности клиенту – Поток замедлился на каждом шаге. Фича проходит каждый этап на 80–480 процентов дольше – Качество просело резко: дефекты вверх, переоткрытые тикеты вверх, code churn (доля переписанного кода) – аномальные 861 процент Узкое место сместилось в ревью. Стадии Ready for Review и In Review раздулись, а ревью стали пропускать на 31 процент чаще – классическое поведение людей на бутылочном горлышке. Сам Faros пишет прямо: организации генерируют больше кода, чем система способна отревьюить и смержить. Автор гоняет данные через закон Литтла (L = λW). Если лид-тайм и WIP растут быстрее, чем заявленная продуктивность – значит скорость потока на самом деле падает. По его расчётам реальная пропускная способность просела на 8–70 процентов в зависимости от допущений. То есть «продуктивность индивидуального разработчика» и «поток готовых фич» поехали в разные стороны, а платят клиенты именно за второе. Тойота в своё время победила американский автопром фанатичным фокусом на качестве и принципе «не передавай дефект на следующую станцию». Чем позже находишь баг, тем дороже он стоит системе. LLM делают ровно наоборот: впрыскивают больше дефектов на входе и переносят их отлов в ревью, где ловить дороже и хуже. Любопытная деталь: гипотеза «AI усиливает сильных» не подтвердилась. High-performing команды деградируют так же, как все остальные. Тут есть с чем спорить по методологии – это наблюдательное исследование, не причинно-следственное, и автор сам это признаёт. Но направление мне кажется честным и совпадает с тем, что многие из нас чувствуют на практике: индивидуальная скорость растёт, а на уровне организации профита не видно. Главная мысль, productivity не равно value. Локальный разгон одного этапа не двигает систему, если узкое место в другом месте. Если внедряешь AI в команду и не перестраиваешь ревью и QA под возросший объём генерации – ты просто переносишь бутылочное горлышко вниз по потоку и копишь work in progress. И отдельно зацепил тезис про «сначала черновик от LLM, потом доработаю». Автор считает, что это задом наперёд: первый черновик – это и есть твой интеллектуальный вклад, момент, когда ты реально продумываешь структуру. LLM сильна как редактор и спарринг после, а не вместо мышления. С этим скорее согласен - чем больше вложений на первых этапах, тем лучше результат. Короче, уделяйте МАКСИМАЛЬНОЕ внимание требованиям, а не пытайтесь зафигачить 100 фич и отдать все тестировщикам. Источник: https://unessays.substack.com/p/talk-is-cheap