Я работаю с владельцем компании, CTO и командой внутри существующего проекта. Цель — не внедрить набор модных практик, а сделать путь изменения от задачи до рабочей системы понятным, проверяемым и воспроизводимым.
Кому подходит
Команде, у которой разработка зависит от устных договорённостей и отдельных людей. Владелец видит непредсказуемые сроки и технологические риски; CTO тратит силы на ручной контроль, повторяющиеся ошибки и аварийные выпуски.
Работа полезна и тогда, когда команда уже использует AI-агентов, но ещё не договорилась, кто отвечает за сгенерированный код и как его принимать.
Что мешает работе команды
- знания о системе сосредоточены у одного человека;
- проверка кода и тестирование нерегулярны;
- окружения расходятся, а выпуск и откат зависят от памяти исполнителя;
- CI/CD существует формально и не подтверждает готовность релиза;
- технический долг растёт без понятных критериев приоритета;
- отчёт AI-агента принимается вместо проверки кода и поведения системы.
Не обязательно иметь все эти проблемы. Начинаем с той, которая сильнее всего мешает поддерживать и развивать продукт.
Формат работы
- На вводной встрече с владельцем или CTO определяем проблему, ожидаемое состояние и границы доступа.
- Прослеживаем путь реального изменения от решения о разработке до выпуска. Фиксируем узкие места, риски и зависимости.
- Выбираем одну зону изменений и договариваемся о критериях готовности.
- Внедряем практику или инфраструктурное решение в текущем проекте: например, проверку кода, минимальный набор тестов или процесс выпуска.
- Проводим через новый маршрут настоящее изменение, проверяем ошибки и возможность отката.
- Документируем правила и передаём практику команде на её задачах.
- Повторно проверяем, что команда применяет процесс без постоянного ручного сопровождения с моей стороны.
Инженерное решение
Конкретный состав зависит от аудита. Я проверяю архитектурные границы, работу с Git, проверку кода, тесты, CI/CD, разделение окружений, конфигурацию, выпуск, откат, журналы работы и мониторинг.
AI здесь остаётся инструментом разработки. Для него нужны те же границы ответственности: проверенный контекст, определённый объём работы, проверка изменений человеком и подтверждение готовности перед выпуском.
Что остаётся у команды
Результатом могут быть схема разработки и список рисков, инженерные стандарты, правила проверки кода, целевые тесты, работающий процесс CI/CD, процедуры выпуска и отката, эксплуатационная документация и правила работы с AI-кодом. Состав фиксируем после аудита.
Критерий готовности — команда провела реальное изменение по новому процессу и может повторить его самостоятельно. Заранее обещать процент ускорения без исходных данных и проверки нельзя.
На какую практику опираюсь
В AKLAB парсеры, очередь, анализатор, рассылка и интерфейс работают как одна система. Этот проект показывает, зачем явно задавать границы сервисов и движение данных. Подход к постановке задач и проверке результата я разбираю в заметке об управлении разработкой с AI-агентом.
Как выбрать соседний формат
Если требуется создать продукт или отдельный модуль, подойдёт разработка веб-систем. Один вопрос можно начать с технологической консультации. Для личного освоения инфраструктуры есть готовая траектория DevOps; обучение одного человека не заменяет изменение процесса команды.