Реддит и Хабр забиты историями о том, как кто-то «написал приложение за вечер с помощью ChatGPT, вообще не зная программирования». Маркетологи называют это вайбкодингом — ты просто описываешь свои намерения, а ИИ выдает готовый продукт.
Я проверил, и вот мой спойлер: на масштабе чуть большем, чем программа на 500 строк, это не работает.
Август 2025 года. Мне понадобилась утилита со сложной логикой: конвертер выгрузок Telegram (JSON) в чистый текст для LLM. Проект десктопный, с GUI, графиками и парсингом. Вместо того чтобы писать код руками, я провел эксперимент: стать техлидом для связки актуальных на тот момент моделей (Claude 4.0 + Gemini 2.5 + Cursor).
Я заранее дал им архитектуру. Они собрали первый MVP. А затем, чтобы этот «MVP» (нет) не сложился как карточный домик через неделю, мне пришлось четырежды инициировать глобальный рефакторинг, потратить 40 часов на борьбу с галлюцинациями вокруг Matplotlib и разгребать цикличные зависимости.
Эта статья — рефлексия и разбор полётов. Это история о том, почему в 2026 году главный навык инженера — это умение видеть деревья за лесом и вовремя сказать ИИ: «Нет, твоя архитектура никуда не годится, всё переделываем».
Архитектура на бумаге и монолит в реальности
Разработку я начал не с main.py. Я скопировал структуру папок из своего старого проекта и попросил Claude: «Сделай так же, но реализуй полноценный Dependency Injection».
Нейросеть сгенерировала красивую файловую структуру. На бумаге всё выглядело как по учебнику: папки core/, presenters/, ui/, services/. Но при попытке добавить первую сложную фичу вылезла реальность — структурная связность была ужасающей.
Иллюзия разделения слоев: Файлы
main_window.py(логика окна) иmain_window_ui.py(вёрстка) импортировали друг друга и наследовались друг от друга. Разделить их было невероятно трудной задачей — они срослись на большинстве уровней, полностью завися друг от друга, действуя как единый скрипт.Презентер-маршрутка: В
MainPresenterнейросеть запихнула вообще всё: от логики чтения JSON до обработки кликов по координатам графика. Это был самый настоящий God Object, который по какой-то нелепой причине был назван презентером.DI для галочки: Контейнер внедрения зависимостей существовал, но 80% сервисов всё равно создавались через прямое
new Service(). ИИ не прокидывал их через конструкторы, он ни капли не заботился о долгосрочной поддержке всего этого ужаса.
Итог: Приложение компилировалось и работало, но изменение одной кнопки ломало три соседних сервиса и подсвечивало массовые гонки состояний. ИИ отлично сымитировал внешнюю форму чистой архитектуры, но сделал это только на уровне названий файлов. Без жёсткого контроля со стороны человека проект мгновенно скатился в процедурную лапшу.
Ловушка паттернов: почему ИИ смешивает бизнес-логику и UI
Самые большие провалы случились с наиболее «кастомными» задумками приложения. Мне нужен был интерактивный график статистики сообщений в стиле KDE Filelight. Я дал Gemini референсный код этого проекта на C++ и попросил по духу адаптировать идею для Python с моими хотелками.
Ошибка №1: Выбор инструмента
И вот тут Gemini подложила мне свинью. Я спрашиваю: на чём рисовать будем? Она: «Matplotlib, так как там проще всего реализовать предложенную задумку». И я поверил... А это, оказывается, библиотека для учёных, а не для GUI (отсюда и тормоза в отрисовке), и даже когда я это осознал, то не хотел её выбрасывать, веря, что «ещё чуть-чуть — и мы сможем оптимизировать отрисовку графика». Мы потратили 40 часов, пытаясь заставить этот научный комбайн работать в десктопном приложении.
Ошибка №2: Отсутствие доменной модели
Чтобы синхронизировать клики по графику и календарь экспорта, ИИ привязал бизнес-логику (какие сообщения пойдут в итоговый текстовый файл) к визуальной структуре UI-дерева графика (год/месяц/день как визуальные узлы) самым топорным способом из возможных.
Вместо того чтобы создать простую абстракцию, ИИ реализовал логику так: мы генерируем древо на основе участков текста, но не «по-нормальному», а «все сообщения внутри 2024-xx-xx — узел 2024 года», а месяц — «все сообщения внутри 2024-10-xx», и всё это цеплялось не к абстрактной логике, где каждый день — отдельная ячейка, а «отдельный кусок текста — это узел». И вот, если отключить 2024 год на диаграмме, а затем включить «декабрь 2024 года» на ней же, то итоговый результат — это либо почти рандом, либо «ошибка».
Решение:
Мы потратили 40 часов на попытки заставить Matplotlib работать быстро и без багов: выстрадали логику соотнесения координат кликов курсора с визуальными сегментами, исправили рассинхрон стейтов, создали логику оптимизации количества сегментов для отрисовки. Но когда тормоза интерфейса стало слишком сложно игнорировать, мой внутренний перфекционизм пересилил страх перед сменой библиотеки. За пару часов мы портировали отрисовку на нативный QGraphicsScene.
Отдельно с ИИ мы переписали логику дат: вместо практически визуального «что экспортировать» появился явный набор выбранных дат (Set[QDate]), и бизнес-логика стала опираться на него же, а бонусом сам график превратился в тупую view, которая просто рисует этот набор.
Дизайн в итерациях и провал мультиагентных систем
О дизайне интерфейса
Claude сделал неплохой стартовый набросок UI, но он выглядел, мягко говоря, криво — как проект студента первого курса IT. Это не мой уровень ожиданий.
Процесс доработки выглядел как диалог с очень быстрым, но безынициативным верстальщиком. Утрированный пример как это происходило:
Я: «Сделай три колонки».
ИИ: (Делает).
Я: «Превью снизу неудобно, перенеси наверх-справа, добавь разделитель».
ИИ: (Делает + ломает сигналы от свичей).
Я: «Markdown отрисовывается некрасиво стандартной библиотекой. Давай лучше заменим на HTML-рендеринг с кастомным CSS».
Вывод: ИИ не придумает UX. Он сделает ровно тот минимум, который вы попросите. Чтобы получить современный интерфейс, мне пришлось итеративно «лепить» его словами и в процессе постигать дзен отладки, когда из-за быстрого прототипирования код регулярно и вполне закономерно ломался.
Про мультиагентов (Cursor)
На волне хайпа я попробовал запустить режим мультиагентов (это было ещё до финального рефакторинга, чтобы провести «стресс-тест»). У меня была конфигурация: один агент правит UI, второй работает по бизнес-логике, третий разрабатывает план дистрибуции под Flatpak и Windows.
Мой вердикт: для пет-проектов с плавающей архитектурой это полностью не работает.
После быстрого мерджа изменений от всех трёх агентов я смотрел на проект и совершенно не понимал: кто из них не справился, а кто выполнил работу только на 20%? Ты пишешь большое ТЗ на две страницы, агенты активно шуршат, а по итогу открываешь, смотришь: «да вроде всё осталось как было, UI тот же, но отпали иконки у кнопок и сломался парсер».
Это похоже на работу в большой неэффективной команде: результатов нет, а с кого спрашивать — не понятно, в отличие от работы с одним агентом. Я думаю, что мультиагенты — отличная задумка, если вам нужно получить 3 разных варианта решения одной проблемы и выбрать лучший. Вероятно, они сработают и на поздних стадиях, когда архитектура уже цельная и ошибиться трудно. Но делить между ними задачи на рыхлой базе MVP — бессмысленная трата времени.
Четыре стадии рефакторинга: от микроменеджмента к автопилоту
Главный миф AI-кодинга: код пишется один раз. Реальность: рефакторинг с ИИ — это непрерывный процесс, где ваша роль эволюционирует по мере «взросления» кодовой базы.
За несколько месяцев я провёл четыре глобальных перестройки.
Стадия 1: Ручное управление (Микроменеджмент)
Прототип работал, но внутри был упомянутый монолит. Я дал команду: «Разбей MainPresenter, раздели ответственность».
Мои ожидания: ИИ заменит 10 файлов, и всё будет работать, я наконец добавлю фичу, о которой думал последний час.
Реальность: 4+ критические ошибки при первом же запуске. Отвалились стили, перестали открываться диалоговые окна, сломалась асинхронщина. Повторные генерации с прошлого сохранения показали ровно тот же результат... Мне пришлось вручную ревьюить каждое изменение, собирать трейсы ошибок и мелкими шажками, на пару с агентом, всё это чинить. Процесс занял несколько дней, а добавление новых фичей постоянно откладывалось, что раздражало ещё больше, чем бесконечный процесс рефакторинга. На данном этапе ИИ требовал полного личного внимания.
Стадия 2: Изоляция компонентов
Второй раз был сфокусирован на выносе сложных кусков, таких как календарь и настройки, в композитные виджеты. Опыт первого рефакторинга помог: я уже знал, где ИИ, скорее всего, схалтурит по глупости и каким образом сломает логику. За счёт этих знаний мы делали меньше итераций и двигались быстрее.
Стадия 3: Разделение слоев (Роль Архитектора)
На третий раз мы перешли к вычищению UI. База уже была в разы лучше, и я наконец мог давать высокоуровневые команды: «Вынеси всю логику парсинга Telegram JSON в отдельный слой Core. UI должен стать тупым и только дергать методы».
Количество циклов «правка–поломка–починка» ещё резче сократилось.
Стадия 4: Автономия (Роль Заказчика)
К четвертому рефакторингу база стала чистой. Я поставил задачу: «Закончи DI. Убери все костыли, убедись, что слои независимы».
И тут случилось неожиданное. Агент начал находить неочевидные баги сам. Тир-лист достижений:
Нашел само-инъекции (где DI-контейнер внедрял зависимости внутрь самого себя).
Выявил «дыры» в инкапсуляции, где слои обращались друг к другу напрямую.
Обнаружил классические гонки данных при быстром клике по UI и сам предложил решение с мьютексами и очередями событий.
Результат: ядро приложения стало настолько независимым, что я смог запустить конвертер в режиме CLI, вообще без импорта PyQt (без графической библиотеки).
Мои выводы: новая реальность разработки
Разработка с помощью LLM — это не генерация кода. Это итеративное управление качеством и техническим долгом, который генерируется со сверхзвуковой скоростью.
Критическое мышление остается на вас. ИИ всегда предложит самое популярное, но не всегда самое верное решение (Matplotlib). Ваша задача — сказать «нет» и спроектировать правильную модель.
Рефакторинг первичен. Сразу после прототипирования с той же ллм нужно действовать максимально внимательно и вручную контролировать первые изменения. И только когда каркас выстроен, нейросети можно доверять задачи «под ключ».
Главная проблема современных моделей в том, что у них напрочь отсутствует здравый смысл. Они поспешно уходят в цикличные попытки починить костыль, заменяя в нём гвозди на шурупы, вместо того чтобы вовремя сменить парадигму, когда это требуется.
Простейший пример: я прошу сделать так, чтобы приложение запоминало свой размер и позицию на экране. ИИ честно пишет код. Из-за асинхронщины и состояния гонки в 5+ местах (непонятно, какой именно сервис закроет окно последним и чьи данные верны) стейт не сохраняется. Что делает ИИ? Вместо того чтобы сказать: «Чувак, у тебя тут гонка данных, если мы не починим архитектуру закрытия, мы никогда не сможем сделать это по Clean Code», он тратит 20$ контекста на то, чтобы написать гениальную внешнюю систему перехвата этих значений перед смертью процесса.
Глядя на итоговый код Tkonverter, я понимаю одну вещь. Моя задача — управлять командой невероятно быстрых стажеров, за которыми нужен глаз да глаз. И, честно говоря, это один из самых сложных и интересных инженерных опытов в истории моих пет-проектов.
Во второй части: как я парсил 100-мегабайтные JSON из Telegram, боролся с лимитами контекста LLM и почему пришлось написать свой UI-тулкит.
Код: GitHub
© 2026 ООО «МТ ФИНАНС»
Комментарии (32)
ProffesorMax
26.02.2026 10:55такое ощущение, что разработка началась не с того конца ))) с ядра надо начинать )
Realife Автор
26.02.2026 10:55А это кстати, один из парадоксальных моментов - начал я с имеющегося примера MVP архитектуры, где уже реализованы механизмы смены тем, языка, логика создания стилей , но не сильно это помогло. По итогу архитектуру пришлось докручивать где-то в середине разработки
Getequ
26.02.2026 10:55Вы упускаете суть, коллега - раньше и мечтать о таком не могли, а сегодня возмущаетесь что в рабочем приложении кривая архитектура. Подождите следующей итерации эволюции нейронок.
Я тоже до недавнего момента плевался почти от каждого ответа, что давала нейронка на вопросы, заданные через чат. С недавнего времени таки втянулся гопотить через copilot в VS
Из воды на сушу тоже не сразу Homo sapiens вылез, а в лучшем случае Тиктаалик. Только эта эволюция протекает буквально на наших глазах как в серии «Любовь. Смерть. Роботы» (1 сезон, 16 серия) (там пара заехала в квартиру и в древнем холодильнике бурлила жизнь)Realife Автор
26.02.2026 10:55В плане развития - действительно, не заметить гигантский рост практически каждые полгода, - невозможно. Но и статья не является сугубо критикой, а описанием моего опыта и мыслей в текущей фазе развития ИИ, так что на пьедестал "технократа" я не претендую, как и вы)
Так gpt 5.3 codex который использовался к поздним этапам, и вовсе удивлял меня тем, насколько быстро и умно, он работал в любой сфере разработки данной программы. Да даже новый Composer удивляет (или что там на режиме auto в Cursor стоит) - уровень от предыдущей итерации вырос с "ну ладно, можешь цифорки в виджет кнопки подправить, чтобы верстка крупнее стала" до "ты очень долго думаешь, но твои решения действительно работают в ~70% случаев, даже в ядре проекта и краевых случаях".
sysbooter
26.02.2026 10:55Суть как раз в том, что ИИ никогда не будет придумывать качественно новые алгогитмы и никогда не превзойдет человека в этом плане, и чем больше нейросети будут развиваться в написании контента в части качества отдельных примитивов не связанных с разработкой алгоритмов и динамикой изменений, тем сильнее они будут запутываться и выдавать лишенную логики мешанину в части создания чего-то качественно нового, что соответственно у них не получится никогда и тем сильнее и быстрее они будут деградировать даже в том что умеют хорошо. И да, хомосапиенс из воды не вылезал и качественно кстати не менялся, создавалась видимость эволюции, а на деле просто развивались те качества, что были уже потенциально вложены в человека изначально, в том числе в части позначания и обучения человека чему-то. То же самое и с ИИ, он будет делать только то, что вложил, а точнее смог вложить в него человек, только чуть быстрее технически, и только.
rPman
26.02.2026 10:55'никогда'? вот прямо 'любой' ИИ?
Кстати, современные LLM нельзя рассматривать в вакууме, только в контексте с используемым агентом и пользовательским промптом. Т.е. это не claude тупой, а это агент, который ради экономии средств, где то что то закешировал, где то пожалел и не 'прочитал' повторно документацию с новым собранным контекстом (я говорю 'агент пожалел' это значит его разработчик не предусмотрел), или к примеру разработчик агента поленился использовать условный EntroPO+R2E (фреймворк, повышающий вариативность ответов модели при запросе вариантов решений), а в лоб модель выдаст первое попавшееся решение, далекое от оптимального.
И вот уже, не до дали информации в контекстное окно на старте, минус 10% к качеству, сэкономили на токенах и использовали rag? еще минус 15%, не стали делать многопроходный анализ с сотнями вариантов, это ведь на порядок дороже, еще минус 10% (благодаря EntroPO+R2E в swebench слабая модель qwen3-coder-30b-a3b поднялась с 51 до 60, стоя на том же уровне что старшая модель но без него)... Но если посчитать стоимость правильного решения, то ИИ становится на столько дорогим, что пользоваться им уже не так интересно.
sysbooter
26.02.2026 10:55вся это смешная реклама вайб кодинга ни к чему. Суть как раз в том, что ИИ никогда не будет придумывать качественно новые алгогитмы и никогда не превзойдет человека в этом плане, и чем больше нейросети будут развиваться в написании контента в части качества отдельных примитивов не связанных с разработкой алгоритмов и динамикой изменений, тем сильнее они будут запутываться и выдавать лишенную логики мешанину в части создания чего-то качественно нового, что соответственно у них не получится никогда и тем сильнее и быстрее они будут деградировать даже в том что умеют хорошо. И да, хомосапиенс из воды не вылезал и качественно кстати не менялся, создавалась видимость эволюции, а на деле просто развивались те качества, что были уже потенциально вложены в человека изначально, в том числе в части позначания и обучения человека чему-то. То же самое и с ИИ, он будет делать только то, что вложил, а точнее смог вложить в него человек, только чуть быстрее технически, и только. И статистика давно свидетельствует постепенную и ускоряющуюся деградацию долговременного применяемого ИИ, особенно на сложных проектах и в контексте усложняющихся моделей.
Komleff
26.02.2026 10:55На дворе февраль 2026, Opus 4.6 и Codex 5.3. Но даже им нужна четкая документация. Мой последний "вайб-проект" — клиент-серверная игра — 40 тысяч строк кода и 50 тысяч строк документации за 40 дней. Всё полностью, включая ГДД, ТЗ, архитектуру, план, код, графику, ревью и деплой на сервер сделано ИИ. Но это, конечно же, не вайб, и не кодинг — это адский труд ПМ по управлению командой из 5-7 агентов. Но в защиту автора смогу сказать, что первые мои шаги в вайб-кодинге выглядели аналогично. Только к пятому за два месяца проекту смог выработать методологию управления проектом. И, сюрприз, ничем не отличается от управления командой из людей.
sysbooter
26.02.2026 10:55Балабольство и реклама это. Никакого выигрыша во времени и трудозатратах это не дает при снижении качества кода и кучи бреда и багов в довесок который плодит ИИ, и еще алгоритмически деградирует. К тому же когда наступит время делать полноценный рефакторинг, да еще и второй-третий, никакой ИИ вам не поможет по целому ряду очевидных причин, и вы не разберетесь в этой лапше если сами не являетесь экспертом по всему стеку примененных технологий или не сами писали код.
Dhwtj
26.02.2026 10:5540 тысяч строк кода
Ну, это если сам отлично знаешь предметную области или есть похожая или почти нет корнер кейсов и вся логика тупая как дуб.
ideological
26.02.2026 10:55Можно ссылочку на результат пожалуйста
50 тысяч строк документации
Ого, это кто-то будет читать?)
Сколько ушло в итоге денег? Окупилось?
Komleff
26.02.2026 10:55https://slime-arena.overmobile.space/
Около 220$:
Claude Opus 4.5 — 100$
ChatGPT 5.2 — 70$
GitHub Copilot — 40$
Gemini 3 Pro — 10$
DeepSeek — 0
Как RnD-проект — окупился десятикратно. Надеюсь в скором времени найти время и доработать проект. Цель — максимально приближенение к коммерческому продукту без скидок на то, что это "домашний пет-проект".
Komleff
26.02.2026 10:5550 тыс строки документации я сам прочитал пока её готовил. А вот 40 тыс кода кому-то когда-то придется ревьювить) Я сам ни строчки не видел и не понимаю.
Тех. стек минимальный:
Node.js
Preact
PostreSQL
Redis
rPman
26.02.2026 10:55Можно сделать финт ушами, попросить не слабую модель проанализировать код и найти недостатки (промпт по заковыкостей составить), собранную информацию рядышком положить и пусть лежит, для ревьювера это будет полезно.
Komleff
26.02.2026 10:55Я постоянно делаю ревью тремя-четврьмя самыми сильными моделями в каждом спринте после каждого цикла кодирования. Готовые отчёты с ревью возвращаются ии-проджект-менеджеру, который их анализирует и отправляет на исправление ии-кодеру.
После 5-7 итераций когда ии-тестировщики уже не выявляют серьезные ошибки, делаю merge. Оставшиеся выявленные, но не исправленные баги сохраняются в таск-трекере Beads и тех долге, обновляется memory_bank, progress.md.
Регулярно, раз в две недели, провожу поиск багов и рефакторинг. Поэтому будущему ревьюверу-человеку придется потрудиться самому)
Dhwtj
26.02.2026 10:55вручную ревьюить каждое изменение, собирать трейсы ошибок и мелкими шажками, на пару с агентом, всё это чинить
Вот странно. Думал, что всякие там агентские системы могут посмотреть UX UI старой системы и новой, сравнить и починить. А так... Дело трудоемкое.
Была задача рефакторинга куска говна строк тыщ на 5 - визард для сложного агрегата а ERP like системе. Были идеи отделить UX UI (HTML CSS JS) в отдельные файлы, небольшие и четкой ответственностью, тогда можно изолировать изменения. На практике в изначальном приложении всё было так тесно переплетено, что проще было рефакторить с одним очень большим файлом несколько дней, пока не стабилизировались границы и контракты. А раз LLM мог менять всё то и
улучшалломал он всё тоже очень быстро.sysbooter
26.02.2026 10:55весьма странно целиком полагаться в таком важном деле как ревью и рефакторинг кода на такой ненадежный инструмент как ИИ. ленность это плохо. у ИИ свой сегмент-чистов вспомогательные функции и обучение, и то ограниченно. но это точно не написание боевого кода и конфигов или обнаружение и боевое реагирование в критических ситуациях. и никогда он не станет надежным боевым инструментом как первой линии, так и даже третьей, и тем более не станет полноценным архитектором. и чем дальше-тем меньше у него шансов на это и тем больше это будет очевидно
vadim_kudr
26.02.2026 10:55Постоянно всем говорю: LLM — это отличный тренажёр по архитектуре. Так и начинаешь постоянно просить о фасадах, инверсии зависимостей, применять разные feature подходы. Тут нужен опыт.
А потом, если выйдете на рынок труда, — будете в шоке. В банках толком нейронок нет, а в других местах LLM опасаются и не спешат переходить. А писать код руками уже не хочется, да и навыки быстрее просаживаются для прохождения собеседований.
Dhwtj
26.02.2026 10:55Ну. Архитектуру и планирование прокачаешь. Код руками просядет, ну и черт с ним.
sysbooter
26.02.2026 10:55вот она, деградация из-за ленности и тупой жадности, так человечество и деградирует, применяя ИИ как волшебную палочку везде где можно и нельзя. это даже не учитываем вопросы безопасности. пока общественное сознание придет в норму, успокоившись после ИИ революции и это изделие займет свою нишевую полку, много дров наломают. и заново обучаться многим придется. и правильно что многие не спешат совершать ошибку и внедрять ИИ всюду.
vadim_kudr
26.02.2026 10:55деградация разной может быть. тут скорее акцент смещается, думаешь больше про архитектуру и читаемость, поддержку. одни навыки растут, а задачки на собеседованиях сложнее щелкать становится. хотя, где-то на собесах уже можно ai пользоваться, причем в крупных компаниях
еще время появляется на обучение того же system design прокачки смежных навыков
свои плюсы и минусы. ошибок по миру будет больше, да и нейро контентом как все загадили... уже видны последствия
а ручное программирование станет как ремесло столяра со стамесками... для остального есть дрель, фрезер и чпу
Dhwtj
26.02.2026 10:55Может, это питон виноват?
Я писал на раст пет вроде Google sheets на минималках: веб, мини движок формул Excel , формирование и мерж ячеек, 1000 пользователей долбятся в один файл, работает, формулы на лету пересчитывает, в БД персистентные данные скидывает батчами из write back кеша, у пользователей всё синхронно.
Получилась идеально чистая архитектура с элементами гексагоналки. Писал LLM. Рефакторить удобно.
d3d11
26.02.2026 10:55Конечно, питон в GUI приложениях - подход так себе.
Dhwtj
26.02.2026 10:55И рефакторить питон не здорово. Это одноразовый код от не программистов.
И какая-то гонка упоминалась
Но тут научные либы, которых возможно нет в других языках.
В общем, Rust для чистой архитектуры и конкуретности вызывает python либы. Норм.
skovoroad
26.02.2026 10:55Мусор на входе - мусор на выходе (и прочие грубые выражения про тз и хз)
Я спрашиваю: на чём рисовать будем? Она: «Matplotlib, так как там проще всего реализовать предложенную задумку». И я поверил...
А не надо верить, это же не волшебство. Надо не полениться и написать два абзаца текста "надо нарисовать такую-то вещь в таких-то условиях с такими-то ограничениями, предложи варианты решений и обрисуй плюсы и минусы". Потом прочитать и сказать: ок, я выбираю такую-то библиотеку по такой-то причине, провалидируй моё решение. Потом прочитать и сказать: по итогам нашего обсуждения сформулируй тз на реализацию этой фичи. Потом прочитать и снова сказать, если есть замечания к этому тз. И только потом уже, с хорошими формулировками тз и готовым контекстом, пусть пишет (по хорошему, ещё описать свои приблизительные ожидания от реализации, но тут важно не переборщить, если сам не знаешь область). После чего снова надо заставлять писать тесты, проводить код-ревью и все хорошие практики.
То есть всё как с программистом-исполнителем невысокого уровня! А если "поверил", то и с человеком-исполнителем такой же результат будет, только с итерациями не в десятки минут, а в дни.
Это если задаться целью получить результат, а не уесть тупую железяку, конечно.
FenixFly
26.02.2026 10:55Подключайте для вайбкодинга spec-kit. Его скилы заставляют сначала прочитать код, потом уточнить задачу, потом разбить на таски, потом имплементировать таски.
0serg
У меня очень схожие ощущения, правда я уж совсем небольшим пет-проектом занимался. Проектик гоняет некую задачу, хочется сохранить промежуточный стейт чтобы если что не запускать с нуля ну и вообще результаты промежуточные где-то лежали.
Решение нейросетки прекрасно: берем все входные данные пишем json, берем от него хэш, пишем выходные результаты в файл (хэш).json. Все отлично работает и корректным образом никогда не подтягивает неверных данных при изменении входных параметров. Вот только делает это лишь для изначально поставленной задачи. На выходе там формировался отчет и мне надо было поитерировать генерацию финального отчета. Для этого требовалось взять тот самый кэш и вытащить из него ранее посчитанные данные. Угадайте насколько легко это было в этой архитектуре сделать? Я так и не сумел подобрать параметры абсолютно идентичные тем что использовал при запуске коллега по хакатону. Плюс куча ненужной функциональности только мешающей читать код.
В целом по ощущениям - если прямо подробно-подробно описать решение словами указав все ключевые решения самостоятельно то все ОК. Чисто "переводить со слов в код" она умеет. А если доверить нейросетке именно "думать", самой придумывать решение, то она с одной стороны что-то работающее придумает, но с другой - поддерживать это потом будет невозможно...
Realife Автор
Да, согласен. У меня в основном все вайбкод проекты как раз таки сталкивались с проблемой, из-за такого "простого" запроса на какую-то фичу. В Improve-ImgSLI основной движок рендера картинки пережил больше 3х этапов полного переосмысления, когда естественным образом хотелось добавить новую функциональность или улучшить существующую.
Как по мне, в случае вайбкодинга, ещё больше больше обостряется потребность, думать на 3 шага вперёд, чтобы не утонуть в переделках "под корень". Промпт не как: "я хочу, чтобы между картинками был слайдер", а "мне нужен механизм отрисовки схожий с GIMP, мы накладываем сплиттер следующим слоем, а картинки делаем текстурами. Используем относительные координаты чтобы, это было масштабируемо, а также по возможности логируем все объекты на сцене"