От микроменеджмента до автопилота: 4 стадии рефакторинга AI-кода на примере десктопного приложения

Реддит и Хабр забиты историями о том, как кто-то «написал приложение за вечер с помощью ChatGPT, вообще не зная программирования». Маркетологи называют это вайбкодингом — ты просто описываешь свои намерения, а ИИ выдает готовый продукт.

Я проверил, и вот мой спойлер: на масштабе чуть большем, чем программа на 500 строк, это не работает.

Август 2025 года. Мне понадобилась утилита со сложной логикой ^[1]: конвертер выгрузок Telegram (JSON) в чистый текст для LLM. Проект десктопный, с GUI, графиками и парсингом. Вместо того чтобы писать код руками, я провел эксперимент: стать техлидом для связки актуальных на тот момент моделей (Claude 4.0 + Gemini 2.5 + Cursor).

Я заранее дал им архитектуру. Они собрали первый MVP. А затем, чтобы этот «MVP» (нет) не сложился как карточный домик через неделю, мне пришлось четырежды инициировать глобальный рефакторинг, потратить 40 часов на борьбу с галлюцинациями вокруг Matplotlib и разгребать цикличные зависимости.

Эта статья — рефлексия и разбор полётов. Это история о том, почему в 2026 году главный навык инженера — это умение видеть деревья за лесом и вовремя сказать ИИ: «Нет, твоя архитектура никуда не годится, всё переделываем».

Архитектура на бумаге и монолит в реальности

Разработку я начал не с main.py ^[2]. Я скопировал структуру папок из своего старого проекта и попросил Claude: «Сделай так же, но реализуй полноценный Dependency Injection».

Нейросеть сгенерировала красивую файловую структуру. На бумаге всё выглядело как по учебнику: папки core/, presenters/, ui/, services/. Но при попытке добавить первую сложную фичу вылезла реальность — структурная связность была ужасающей.

1. Иллюзия разделения слоев: Файлы main_window.py (логика окна) и main_window_ui.py (вёрстка) импортировали друг друга и наследовались друг от друга. Разделить их было невероятно трудной задачей — они срослись на большинстве уровней, полностью завися друг от друга, действуя как единый скрипт.

2. Презентер-маршрутка: В MainPresenter нейросеть запихнула вообще всё: от логики чтения JSON до обработки кликов по координатам графика. Это был самый настоящий God Object, который по какой-то нелепой причине был назван презентером.

3. DI для галочки: Контейнер внедрения зависимостей существовал, но 80% сервисов всё равно создавались через прямое new Service(). ИИ не прокидывал их через конструкторы, он ни капли не заботился о долгосрочной поддержке всего этого ужаса.

Итог: Приложение компилировалось и работало, но изменение одной кнопки ломало три соседних сервиса и подсвечивало массовые гонки состояний. ИИ отлично сымитировал внешнюю форму чистой архитектуры, но сделал это только на уровне названий файлов. Без жёсткого контроля со стороны человека проект мгновенно скатился в процедурную лапшу.

Ловушка паттернов: почему ИИ смешивает бизнес-логику и UI

Самые большие провалы случились с наиболее «кастомными» задумками приложения. Мне нужен был интерактивный график статистики сообщений в стиле KDE Filelight. Я дал Gemini референсный код этого проекта на C++ и попросил по духу адаптировать идею для Python с моими хотелками.

Ошибка ^[4] №1: Выбор инструмента
И вот тут Gemini подложила мне свинью. Я спрашиваю: на чём рисовать будем? Она: «Matplotlib, так как там проще всего реализовать предложенную задумку». И я поверил… А это, оказывается, библиотека для учёных, а не для GUI (отсюда и тормоза в отрисовке), и даже когда я это осознал, то не хотел её выбрасывать, веря, что «ещё чуть-чуть — и мы сможем оптимизировать отрисовку графика». Мы потратили 40 часов, пытаясь заставить этот научный ^[5] комбайн работать в десктопном приложении.

Ошибка №2: Отсутствие доменной модели
Чтобы синхронизировать клики по графику и календарь экспорта, ИИ привязал бизнес-логику (какие сообщения пойдут в итоговый текстовый файл) к визуальной структуре UI-дерева графика (год/месяц/день как визуальные узлы) самым топорным способом из возможных.

Вместо того чтобы создать простую абстракцию, ИИ реализовал логику так: мы генерируем древо на основе участков текста, но не «по-нормальному», а «все сообщения внутри 2024-xx-xx — узел 2024 года», а месяц — «все сообщения внутри 2024-10-xx», и всё это цеплялось не к абстрактной логике, где каждый день — отдельная ячейка, а «отдельный кусок текста — это узел». И вот, если отключить 2024 год на диаграмме, а затем включить «декабрь 2024 года» на ней же, то итоговый результат — это либо почти рандом, либо «ошибка».

Решение:

Мы потратили 40 часов на попытки заставить Matplotlib работать быстро и без багов: выстрадали логику соотнесения координат кликов курсора с визуальными сегментами, исправили рассинхрон стейтов, создали логику оптимизации количества сегментов для отрисовки. Но когда тормоза интерфейса стало слишком сложно игнорировать, мой внутренний перфекционизм пересилил страх ^[6] перед сменой библиотеки. За пару часов мы портировали отрисовку на нативный QGraphicsScene.

Отдельно с ИИ мы переписали логику дат: вместо практически визуального «что экспортировать» появился явный набор выбранных дат (Set[QDate]), и бизнес-логика стала опираться на него же, а бонусом сам график превратился в тупую view, которая просто рисует этот набор.

Дизайн в итерациях и провал мультиагентных систем

О дизайне интерфейса

Claude сделал неплохой стартовый набросок UI, но он выглядел, мягко говоря, криво — как проект студента первого курса IT. Это не мой уровень ожиданий.

Процесс доработки выглядел как диалог с очень быстрым, но безынициативным верстальщиком. Утрированный пример как это происходило:

• Я: «Сделай три колонки».

• ИИ: (Делает).

• Я: «Превью снизу неудобно, перенеси наверх-справа, добавь разделитель».

• ИИ: (Делает + ломает сигналы от свичей).

• Я: «Markdown отрисовывается некрасиво стандартной библиотекой. Давай лучше заменим на HTML-рендеринг с кастомным CSS».

Вывод: ИИ не придумает UX. Он сделает ровно тот минимум, который вы попросите. Чтобы получить современный интерфейс, мне пришлось итеративно «лепить» его словами и в процессе постигать дзен отладки, когда из-за быстрого прототипирования код регулярно и вполне закономерно ломался.

Про мультиагентов (Cursor)

На волне хайпа я попробовал запустить режим мультиагентов (это было ещё до финального рефакторинга, чтобы провести «стресс-тест»). У меня была конфигурация: один агент правит UI, второй работает по бизнес-логике, третий разрабатывает план дистрибуции под Flatpak и Windows.

Мой вердикт: для пет-проектов с плавающей архитектурой это полностью не работает.
После быстрого мерджа изменений от всех трёх агентов я смотрел на проект и совершенно не понимал: кто из них не справился, а кто выполнил работу только на 20%? Ты пишешь большое ТЗ на две страницы, агенты активно шуршат, а по итогу открываешь, смотришь: «да вроде всё осталось как было, UI тот же, но отпали иконки у кнопок и сломался парсер».

Это похоже на работу в большой неэффективной команде: результатов нет, а с кого спрашивать — не понятно, в отличие от работы с одним агентом. Я думаю, что мультиагенты — отличная задумка, если вам нужно получить 3 разных варианта решения одной проблемы и выбрать лучший. Вероятно, они сработают и на поздних стадиях, когда архитектура уже цельная и ошибиться трудно. Но делить между ними задачи на рыхлой базе MVP — бессмысленная трата времени.

Четыре стадии рефакторинга: от микроменеджмента к автопилоту

Главный миф AI-кодинга: код пишется один раз. Реальность: рефакторинг с ИИ — это непрерывный процесс, где ваша роль эволюционирует по мере «взросления» кодовой базы.

За несколько месяцев я провёл четыре глобальных перестройки.

Стадия 1: Ручное управление (Микроменеджмент)
Прототип работал, но внутри был упомянутый монолит. Я дал команду: «Разбей MainPresenter, раздели ответственность».

Мои ожидания: ИИ заменит 10 файлов, и всё будет работать, я наконец добавлю фичу, о которой думал последний час.
Реальность: 4+ критические ошибки при первом же запуске. Отвалились стили, перестали открываться диалоговые окна, сломалась асинхронщина. Повторные генерации с прошлого сохранения показали ровно тот же результат… Мне пришлось вручную ревьюить каждое изменение, собирать трейсы ошибок и мелкими шажками, на пару с агентом, всё это чинить. Процесс занял несколько дней, а добавление новых фичей постоянно откладывалось, что раздражало ещё больше, чем бесконечный процесс рефакторинга. На данном этапе ИИ требовал полного личного внимания ^[7].

Стадия 2: Изоляция компонентов
Второй раз был сфокусирован на выносе сложных кусков, таких как календарь и настройки, в композитные виджеты. Опыт ^[8] первого рефакторинга помог: я уже знал, где ИИ, скорее всего, схалтурит по глупости и каким образом сломает логику. За счёт этих знаний мы делали меньше итераций и двигались быстрее.

Стадия 3: Разделение слоев (Роль Архитектора)
На третий раз мы перешли к вычищению UI. База уже была в разы лучше, и я наконец мог давать высокоуровневые команды: «Вынеси всю логику парсинга Telegram JSON в отдельный слой Core. UI должен стать тупым и только дергать методы».
Количество циклов «правка–поломка–починка» ещё резче сократилось.

Стадия 4: Автономия (Роль Заказчика)
К четвертому рефакторингу база стала чистой. Я поставил задачу: «Закончи DI. Убери все костыли, убедись, что слои независимы».
И тут случилось неожиданное. Агент начал находить неочевидные баги сам. Тир-лист достижений:

1. Нашел само-инъекции (где DI-контейнер внедрял зависимости внутрь самого себя).

2. Выявил «дыры» в инкапсуляции, где слои обращались друг к другу напрямую.

3. Обнаружил классические гонки данных при быстром клике по UI и сам предложил решение с мьютексами и очередями событий.

Результат: ядро приложения стало настолько независимым, что я смог запустить конвертер в режиме CLI, вообще без импорта PyQt (без графической библиотеки).

Мои выводы: новая реальность разработки

Разработка с помощью LLM — это не генерация кода. Это итеративное управление качеством и техническим долгом, который генерируется со сверхзвуковой скоростью.

1. Критическое мышление ^[9] остается на вас. ИИ всегда предложит самое популярное, но не всегда самое верное решение (Matplotlib). Ваша задача — сказать «нет» и спроектировать правильную модель.

2. Рефакторинг первичен. Сразу после прототипирования с той же ллм нужно действовать максимально внимательно и вручную контролировать первые изменения. И только когда каркас выстроен, нейросети можно доверять задачи «под ключ».

Главная проблема современных моделей в том, что у них напрочь отсутствует здравый смысл. Они поспешно уходят в цикличные попытки починить костыль, заменяя в нём гвозди на шурупы, вместо того чтобы вовремя сменить парадигму, когда это требуется.

Простейший пример: я прошу сделать так, чтобы приложение запоминало свой размер и позицию на экране. ИИ честно пишет код. Из-за асинхронщины и состояния гонки в 5+ местах (непонятно, какой именно сервис закроет окно последним и чьи данные верны) стейт не сохраняется. Что делает ИИ? Вместо того чтобы сказать: «Чувак, у тебя тут гонка данных, если мы не починим архитектуру закрытия, мы никогда не сможем сделать это по Clean Code», он тратит 20$ контекста на то, чтобы написать гениальную внешнюю систему перехвата этих значений перед смертью процесса.

Глядя на итоговый код Tkonverter, я понимаю одну вещь. Моя задача — управлять командой невероятно быстрых стажеров, за которыми нужен глаз да глаз. И, честно говоря, это один из самых сложных и интересных инженерных опытов в истории моих пет-проектов.

Во второй части: как я парсил 100-мегабайтные JSON из Telegram, боролся с лимитами контекста LLM и почему пришлось написать свой UI-тулкит.

Код: GitHub ^[10]

© 2026 ООО «МТ ФИНАНС»