Генерация кода: сокращаем рутину в разработке Задача простая: во всей кодовой базе поменять print на logger.info. Поиском и заменой не выйдет, заденешь комментарии, где print просто упомянут словом. Синтаксическое дерево умнее — проходит по узлам, находит именно вызовы print, меняет только их. Но у абстрактного дерева (AST) своя цена. Код после трансформации становится чище и теряет всю документацию, потому что комментарии и форматирование оно не хранит в принципе. То есть безопасно рефакторить внутри репозитория им нельзя. Автоматизация давно не роскошь, а базовый минимум, и жертвовать читаемостью ради неё смысла нет. Остаётся третий инструмент, который держит всю структуру от запятых до комментариев. Посмотрим, чем конкретное синтаксическое дерево закрывает то, на чём спотыкаются два предыдущих.

Лучший ход Кажется, я долго искал критерий хорошего архитектурного решения. Сейчас думаю про четыре штуки, которые одновременно делает "лучший ход":

1. Даёт локальную пользу уже сейчас. 2. Уменьшает глобальный разрыв в системе 3. Делает следующий хороший ход дешевле. 4. Увеличивает вероятность того, что этот путь повторят другие.

Последний пункт кажется самым важным. Если решение приходится каждый раз продавливать заново, ландшафт не изменился. Настоящий рефакторинг: изменение формы поверхности, по которой движется вся система, без переписывания кода.

После хорошего рефакторинга правильное решение начинает требовать меньше усилий, чем неправильное.

Возможно, именно это и является настоящей единицей эволюции сложных систем. Если так смотреть, эволюция сложных систем идёт не через новые объекты, функции или процессы. Она идёт через сдвиги в стоимости следующего перехода. Хороший пример из нашей работы — текстовый daily в Slack по шаблону «доставлено / планирую / блокеры». Проверяется по всем четырём пунктам: Локальная польза сейчас — утром за 2 минуты команда видит, кто чем занят, без созвона. Закрывает разрыв — не нужно дёргать людей в личку «ну что там у тебя», блокеры всплывают сами. Удешевляет следующий шаг — если у кого-то затык, помочь можно сразу, а не когда уже сгорело. Повторяют другие — новый человек в команде заходит в канал, смотрит вверх, копирует формат. Никто не объясняет заново. Форма поверхности изменена: написать по шаблону дешевле, чем не написать. Поэтому шаблон живёт сам, без напоминаний. А теперь посмотрите на свою команду. Поищите такие примеры — где хороший ход стал дешевле плохого сам собой, без напоминаний и продавливания. Делитесь в комментариях. Давайте обмениваться опытом 👇

Как экономить контекст в coding agent (claude, codex etc.) Задача переписать легаси на сотни тысяч строк кода, которая разрабатывалась (криво и косо) на протяжении 5 лет, за 3 месяца. Сюда входит погрузиться: в продукт, инфру, архитектуру, нагрузку, тестирование и проч. Чтобы успеть, нужно смерживать десятки PR/день. Когда нибудь напишу, как мы построили процесс, а пока простые мысли, как экономить контекст, ибо что в лимиты упираешься постоянно. 1) Субагенты строго через младшую модель. Пример: Opus 5 оркестратор, Sonnet 5 субагенты. Идеальный сценарий когда младшая никогда модель не принимает никаких решений. 2) `/compact` каждые ~150k токенов: сейчас, когда у моделей по 1м контекстного окна, мозгу кажется что 250k это всего лишь 1/4, то есть мало, а по факту 250k это 250k, и с каждым след.запросом стоимость возрастает. Какое бы не было контекстное окно, я держусь в минимальных пределах. 3) По одной задаче на чат: допускал ошибку, когда давайл скоуп задач в стиле "/goal работай пока не закроешь все". Работает херово. Не потому даже что модель путается, а просто потому что вам так сложнее понять статус и прогресс. Понимание происходящего ценно, держитесь за него. Еще помогают четко описанные задачи, но это уже не просто об оптимизации токенов, а в целом о качестве. Пример секций: что делаем, зачем, что входит в задачу а что нет, как проверить задача успешно выполнена.

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

ПРОКЛЯТИЕ ПЕРЕИСПОЛЬЗУЕМОСТИ Делюсь болью. Я последние 5 лет на разных уровнях у разработчиков, лидов и техдиректоров, активно встречаю такой паттерн:

Ну давай просто выделим общее и переиспользуем это в другой системе/проекте.

Мы ведь уже написали систему перемещения для ботов, давайте для игрока её тоже переиспользуем. У нас ведь уже есть backend-сервис по обработке match-3 логики, давайте его же тупо используем в другой игре 😵 Может казаться, что нужно просто скопировать/вставить решения из одного места или создать общий класс. И черт, это не работает нормально в большинстве случаев. 🔸 Если вы делаете что-то общее, то сначала нужно понять, какие зависимости это общее в себя принимает и отдаёт Если вы сделаете прямой copy/paste, придётся писать кучу обёрток, чтобы подружить новую систему с текущей. Поэтому чтобы действительно такое было возможно, нужно заранее проектировать не только саму систему абстрактно, но и её зависимости 🤯 А это значит, что нужно изначально планировать проектирование ключевых абстракций проекта. Например: 🔹 Весь cross-cutting context. Логирование, конфиги, аналитика, обработка ошибок. Либо придётся кучу мест рефакторить, либо заранее согласовывать единое API для переиспользования между проектами. 🔹 Коммуникация с сервером — пример посложнее. Но суть простая: вы не хотите при переносе дублировать логику обработки ошибок, контрактов взаимодействия и тянуть лишние транзитивные зависимости (другой HTTP-плагин, например). И это важно тупо потому, что это заставляет поддерживать задублированные решения по проекту 🤢 🔹 Изменился формат логирования или когда логи пишутся, а когда нет 🔹 Добавился новый обработчик исключений, формат контракта или обработка краевого случая Вот иди свищи по проекту 10 копий и вкостыливай фикс и туда. При этом ладно этот фикс в коде, ха, это ещё изи, а если ты решил общий микросервис такой выделить… 🔻Чем больше расстояние между зависимостями — тем сложнее и дороже в них вносить изменения. 🔸 Не всё, что кажется общим, таковым является Избитый троп:

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

Ну нет, это не работает. Если заранее не понимать, как именно система будет переиспользоваться, и не переиспользовать сразу — оно не будет работать. Это происходит из одного простого факта: 🔹 Скорость изменения требований разная для каждой из систем. То, что вчера виделось как общее, сегодня жёстко заточено под что-то конкретное, т.к. переиспользуемость стоит времени, сил, денег и тщательного планирования. Или по другому: То что вчера казалось легко можно переиспользовать, сегодня требует узкого и конкретного решения. Так что всё, пожалуйста, я снимаю со всех, кто читает этот пост, «проклятие переиспользуемости» 😘 С этого момента вы можете не писать системы так, чтобы вдруг когда-то их кто-то использовал и сократил себе время. 🔻 Наконец-то можно писать системы, которые заточены на выполнение своей задачи и не раздувают сложность проекта на ровном месте. Но если переживаете, вот правило трёх:

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

А если есть требование — выровняйте уровень знаний, покажите цену такого решения, сделайте #проектирование@UniArchitect, внедрите и пользуйтесь на здоровье, все только спасибо скажут. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #проект_в_разработке@UniArchitect