Проекты
Закрытые кейсы: что болело у бизнеса, что я сделал и что изменилось.
Технические детали каждого кейса открываются кнопкой «Показать детали».
2025–2026 · Raft, AI Labs · тимлид и техлид
AI-аудит медкарт: за месяц до сдачи — из хаоса в прод без сбоев
Крупная сеть клиник ждала платформу оценки качества ведения медкарт. За месяц до сдачи проект был в хаосе: лид ушёл из компании, заказчик менял требования на ходу, а API, с которым предстояло интегрироваться, ещё не существовало. Принял проект: зафиксировал с заказчиком требования и точки интеграции, вернул команде рабочий ритм и наладил связку AI- и backend-разработки. Релиз за 2 дня, после сдачи ни одного инцидента; проект победил в Yandex B2B Tech Awards.
Команда из пяти человек, три с половиной месяца моего участия. Два сервиса в одном монолите на FastAPI с Postgres и Redis; RabbitMQ развязал бэкенд, LLM-сервис и API заказчика, которое дорабатывалось параллельно с нами; размещение в Yandex Cloud. С заказчиком договаривались гибко: обоснованные требования приняли, остальные отстояли. Помимо координации и переговоров сам разбирал баги и писал бэкенд; backend-разработчик за эти месяцы вырос из неуверенного мидла в уверенного.
Новый сервис в прод за часы: монорепозиторий с первого дня
На прошлых проектах видел, во что обходится расползание доменных и ORM-моделей по репозиториям: изменение контракта в одном сервисе ломает соседние, а вывод нового сервиса занимает дни. Новый продукт на микросервисах с первого дня строил в монорепозитории с общими библиотеками и единым конвейером поставки. Новый сервис выходит в прод за пару часов, а рассинхрон контрактов исключён самой конструкцией.
Общие доменные и ORM-модели в одной библиотеке, атомарные изменения сразу во всех затронутых сервисах, синхронное обновление зависимостей, шаблоны развёртывания и один CI/CD-пайплайн на все сервисы.
Разработка с AI-агентами: быстро на старте и управляемо потом
С агентами MVP собирают за две недели, а потом полгода не могут в нём разобраться: быстрый старт не равен продукту, который можно сопровождать и развивать. Выстроил для команды единое стандартизированное поле агентной разработки: правила кодовой базы, которым подчиняются ассистенты, внутренний сервер проектного контекста, автогенерация тестов на каждый PR и проверки ещё до коммита. Разработка с агентами стала предсказуемой: код от агентов проходит те же правила и тесты, что и написанный людьми, и продукт остаётся управляемым после старта.
Сервер контекста (MCP) отдаёт модели только актуальные схемы данных, доменные инварианты и стандарты репозитория вместо раздутых статических промптов. Конвейер в CI анализирует дифф каждого PR и генерирует юнит-тесты по шаблонам проекта. Правила кодовой базы систематизируют типовые ошибки LLM-генерации; pre-commit хуки перенесли линтинг и форматирование на этап коммита и разгрузили CI. Главный вывод: подходов два. Либо код на 100% пишет агент, и тогда контроль качества тоже его: правила, ревью, полное покрытие вплоть до e2e. Либо гибрид: агент пишет архитектуру, каркас и тесты, а бизнес-логику — человек. Дольше, но проект остаётся управляемым.
2015–2024 · Northern Light, Бостон · от software engineer до principal engineer
Поисковые порталы по синдицированным и внутренним данным для менеджмента 20 компаний-клиентов, среди них J&J, IBM, HP и Intel: более 30 сервисов, 100+ ТБ контента, режим 24/7. Отвечал за стабильность всей инфраструктуры, на которой стоит продукт.
Perl → Python: легаси перестало быть риском для бизнеса
Загрузка и обработка данных были написаны на Perl: писать на нём умели единицы, новых инженеров под него не нанять, каждая правка стоила дорого и делалась кто во что горазд. Платформа, работающая 24/7, держалась на знаниях нескольких человек. Перевёл кодовую базу на Python поэтапно, пока платформа продолжала работать: новые компоненты вставали рядом со старыми и забирали их работу по одному. Perl перестал быть риском: код понятен всей команде, инженеров можно нанимать с рынка, изменения стали дешёвыми и предсказуемыми.
Сначала Python 2, затем 3. Первыми переехали загрузчики, за ними фильтры обработки, по одному компоненту. Параллельно построил тестовую обвязку: функциональные и приёмочные тесты на ядро и извлечение текста, чтобы перенос не ломал то, что работало.
Подключение источника данных: 3–7 дней вместо 30
Сотня с лишним поставщиков данных, от веб-страниц и API до FTP и SharePoint, и каждый новый источник означал месяц работы: загрузчик и обработка писались под него с нуля, а любое отклонение в формате ломало конвейер. Собрал все загрузчики в единый фреймворк и встроил в него нормализацию: на выходе каждый документ всегда в одном формате, и обработка дальше по конвейеру стала простой. Подключение нового источника занимает 3–7 дней вместо 30.
Фреймворк на Python и Scrapy заменил три класса загрузчиков: RSS, краулеры и кастомные для экзотики вроде SOAP, FTP и SharePoint. Загрузчик знает об источнике всё, поэтому нормализация живёт в нём: на выходе всегда пара «метаданные + документ». Сюда же вошёл разбор документов (HTML, PDF, сканы) до блоков и предложений с очисткой от меню, дисклеймеров и колонтитулов. Типичный тикет на новый источник содержал только доступы к нему и закрывался через три дня.
Клиентская отчётность перестала ломаться каждый месяц
Отчёты об активности на порталах для 100+ менеджеров из 20 компаний-клиентов собирались из текстовых логов бэкенда: парсеры ошибались, данные терялись, а ежемесячная генерация перегружала систему. Несколько лет первая неделя каждого месяца уходила на восстановление отчётов и объяснения. Доказал, что портал уже владеет всеми данными для отчётов, и провёл переход на событийную модель: порталы пишут события напрямую в аналитический стек. Сбои и претензии прекратились; клиенты получили отчёты за любой интервал и за текущий день.
События в JSON Lines, которые нативно ложатся в ELK, вместо разбора логов регулярными выражениями; реализацию передал командам UI и devops. Пока решение согласовывали, держал старую систему на плаву: чинил бэкенд и оптимизировал индексы Postgres под выборки по интервалам дат. Самым сложным было не техническое решение, а организационное: систему, в которую вложили много ресурсов, пришлось признать негодной и провести замену через сопротивление.