Программная инженерия
Для меня программная инженерия — это способность менять систему, не теряя над ней контроль. Архитектура — не схема на стене. Это набор решений, которые продолжают работать, когда сдвинулись команда, нагрузка и сам продукт.
Большую часть карьеры я работал внутри уже больших систем: платёжные и рекламные стеки, игровые бэкенды, контентные платформы. Это редко была чистая разработка с нуля. Это была задача снова научить зрелый код поставлять изменения, удержать ментальную модель достаточно маленькой для команды и не принять случайную сложность за прогресс.
Этот раздел — про этот слой. Архитектура и ответственность. Эволюция legacy. Поставка и надёжность. Ревью кода как способ держать общий стандарт. Тесты как контракт с будущим. Разработка с AI тоже здесь: не как отдельная религия, а как изменение скорости правок, которое по-прежнему требует инженерного суждения.
Система здорова, если компетентная команда всё ещё может её объяснить, изменить и выкатить. Всё остальное — декорация.
-
Agent-ready codebase: как подготовить код к AI-агентам
Как Git, ACDD, DDD, SOLID, тесты, документация, бэклог и линтеры помогают AI-агентам понимать кодовую базу и безопасно изменять легаси-системы.
-
Code review с AI: что проверять, когда код стало слишком легко писать
AI удешевил написание кода, но не понимание. Review смещается с синтаксиса на intent, scope, архитектуру и вопрос, должен ли этот код вообще существовать.
-
Кто отвечает за код, написанный AI
AI поменял, кто производит текст, но не то, кто решает оставить его в системе. Ownership остаётся у человека, который понимает изменение и принимает merge.
-
Атомарные коммиты и ACDD: порядок в Git и AI-разработке
Что такое атомарный коммит, как определить его границы, писать сообщения, вести чистую историю Git и контролировать изменения, созданные AI.
-
Как внедрить AI в legacy-систему без переписывания проекта
Legacy остаётся system of record, а AI появляется рядом как новый слой: adapters, read-only сценарии, shadow mode и постепенное расширение возможностей.