Двадцать лет создаю софт и компании, сейчас фокус на AI-системах: приложения на LLM, RAG-пайплайны, мультиагентные архитектуры и вся инженерная основа вокруг них. Берусь за настоящие бизнес-задачи — как архитектор и как старший разработчик, часто и то и другое. Важен результат: решение, которое делает то, что реально нужно вашим пользователям, и которое можно развивать дальше, а не код, который один раз отработал. Если это стоящий, интересный проект, где всё решает качество инженерии, — расскажите.
Почему за архитектуру стоит платить
Больше всего я ценю заказчиков, которые понимают важность архитектуры и готовы вложиться в те несколько решений, от которых зависит всё остальное. Эти вложения окупаются. Обратный подход — «сделаем на коленке» — почти всегда упирается в тупик: приложение не делает того, что на самом деле нужно пользователю, и его невозможно развивать, потому что код не следовал базовым принципам (SOLID, DRY, KISS, dependency injection). Несколько верных решений в начале — это то, что спасает вас от переписывания через год. Писать код я люблю и умею — я старший разработчик и им останусь, — но хочу, чтобы то, что мы строим, стоило построить хорошо.
Форматы сотрудничества
Проектирую и строю, внутри команды
3–6 месяцев, внутри одной команды. Проектирую AI-систему: retrieval, работу с инструментами, оркестрацию, evals, MCP-интеграции, слой данных, границы безопасности — и строю её или ревьюю сборку по мере выкатки. Одна LLM в контуре или полноценная мультиагентная топология — в зависимости от того, что действительно требует задача. Несущие части пишу сам, а для остального оркестрирую coding-агентов; в любом случае спецификация, дизайн и ревью — за мной. Подходит, когда вы уже прошли прототип и следующая версия должна выдержать контакт с продакшеном.
Архитектурное ревью
1–3 недели, письменный результат. Взгляд senior-инженера на систему, которую вы уже спроектировали, или на систему, которая ведёт себя не так, как хотелось. На выходе — письменный отчёт: что держит нагрузку, что хрупко, что я бы изменил в первую очередь и почему. Короткий формат, без обязательств на длинную дистанцию. Ещё не уверены, что нужно ревью? AI Architecture Scorecard — бесплатная self-serve версия: шесть измерений и приоритизированная оценка того, где вы стоите, примерно за три минуты.
Полная занятость
Senior AI-инженер и архитектурные позиции в компаниях, где относятся к инженерному качеству серьёзно и «ship it» — второе предложение, а не первое. Как называется роль — архитектор или старший разработчик — важно меньше, чем то, настоящая ли работа. В принципе открыт, на практике избирателен.
Как работаю
- Артефакт — это спецификация, а не промпт и не код. Чёткая спецификация сильнее умной реализации, и именно о ней команда фактически рассуждает.
- Eval или не выпущено. Поведение, которое стоит отправлять в продакшен, стоит зафиксировать — я ожидаю holdout-набор сценариев для любого агента, которому предстоит реальная работа. Почему именно так.
- Один источник правды на факт. Дублирование состояния — это дублирование багов. Активно ищу это на ревью.
- Скучные технологии там, где можно. Postgres, FastAPI, Next.js. Новизна принадлежит AI-слою; подложка должна быть предсказуемой.
- Асинхронность по умолчанию. Длинный текст > коротких созвонов. Решения фиксируются в документах, чтобы следующему человеку не пришлось открывать их заново.
Полнее эти принципы изложены в манифесте AI-native архитектуры.
Чего я не беру
Я открыт к интересной работе, но не ко всему подряд. Где я плохо подхожу:
- Чистый staff augmentation — место, которое нужно занять под фиксированную спецификацию, без права голоса в том, как всё устроено. Я в лучшей форме, когда дизайн — часть задачи, а не отдан мне как уже решённое.
- Проекты без production-цели. Мне интересны системы, которые должны пережить утро понедельника, а не демо, которому нужно пережить вечер вторника.
- Проекты, где «быстро и на выброс» — и есть настоящая цель. Если план в том, чтобы сделать на коленке и никогда не поддерживать, — я не тот человек: не там я приношу пользу.
Бэкграунд
Двадцать лет в backend-системах, распределённых данных, платежах, SaaS на LLM, а теперь — в AI-архитектуре для продакшена. Выпускал продукты в маленьких стартапах и в масштабе; вёл команды и работал как individual contributor. Сквозная линия — инженерное суждение в реальных ограничениях. Полное резюме здесь.
Как связаться
Самый быстрый путь — написать на email: fedorstartup@gmail.com. Расскажите, что вы строите, на какой стадии проект и по чему именно нужен внешний взгляд. Я читаю всё и отвечаю в течение нескольких дней; длинные письма приветствуются. Можно и через контактную форму.