Восемь лет желания, три месяца разработки с ИИ
- title
- Восемь лет желания, три месяца разработки с ИИ
- type
- summary
- summary
- Провал vibe coding'а, дисциплинированная переработка, цикл зависимости и почему проектирование нельзя делегировать
- tags
- ai-agents, software-quality, vibe-coding
- sources
- building-syntaqlite-ai
- created
- 2026-04-08
- updated
- 2026-09-13
- lang
- ru
- translation_of
- building-syntaqlite-ai
- source_updated
- 2026-09-13
- translated
- 2026-09-14
- translator
- lllm/antigravity/gemini-3.7-flash-medium
Лалит Маганти (Google, мейнтейнер PerfettoSQL) восемь лет хотел сделать нормальные инструменты разработки для SQLite, но так и не начинал - работа была слишком муторной. С помощью ИИ-агентов для кодинга он написал и выпустил syntaqlite за три месяца. Но на этом пути был целый месяц создания прототипа в режиме vibe coding'а, который пришлось выбросить целиком. Пост подкупает редкой честностью о том, где ИИ помог, а где откровенно навредил.
Две фазы
Фаза 1: Vibe coding (январь 2025). Полное делегирование Claude Code на тарифе Max. Получился рабочий прототип: C-парсер, извлечённый из исходников SQLite, форматировщик, поддержка PerfettoSQL, веб-песочница, 500+ тестов. Но кодовая база оказалась "полнейшим спагетти" - невнятная архитектура, функции разбросаны по файлам. Прототип доказал жизнеспособность подхода, но потребовал полной переделки с нуля.
Фаза 2: Дисциплинированное использование ИИ (февраль-март). Переписал всё на Rust, взяв на себя роль архитектора. ИИ стал "автодополнением на стероидах" - Маганти сам принимал все проектные решения, заранее продумывал архитектуру, выстроил инфраструктуру валидации и проверял каждую сгенерированную строчку. В середине марта результат вышел в релиз как syntaqlite 0.1.
Контраст между этими фазами - главный практический вывод статьи. Один и тот же человек, те же инструменты ИИ, тот же проект - и радикально разные результаты в зависимости от того, занимался ли человек проектированием.
Где ИИ помог
Преодоление инерции. Проект простаивал 8 лет, потому что извлечение порядка 400 грамматических правил SQLite и построение деревьев разбора было делом нудным, но требовательным. ИИ превратил абстрактный паралич в конкретные прототипы. "Мне намного проще работать, когда можно пощупать живой прототип и посмотреть на код, чем бесконечно крутить варианты архитектуры в голове". Одно это уже оправдало месяц vibe coding'а: пусть код и пошёл под нож, он сдвинул дело с мёртвой точки.
Быстрое написание очевидного кода. Реализация функций по заданной спецификации поведения и интерфейсу. Идеальной задачей стали правила форматировщика: благодаря тестовой обвязке, позволявшей проверять результат за считаные минуты, итерации шли поразительно быстро. Кроме того, ИИ держит единый стиль и документирует то, что человек обычно пропускает.
Дешёвый рефакторинг. Благодаря высокой скорости генерации рефакторинг перестаёт быть дорогим. Непрерывный рефакторинг на второй фазе не позволил долгу накапливаться - болезненный урок первой фазы, где нехватка рефакторинга быстро превратила проект в безнадёжную кашу.
Погружение в смежные области. Изучение алгоритмов красивого вывода Wadler-Lindig, непривычного инструментария Rust, API расширений для VS Code - темы, на самостоятельное освоение которых ушли бы дни, сжались в часы сфокусированного диалога. Можно было выспрашивать "почему это работает?", пока суть не становилась полностью понятна.
Полнота возможностей. Помимо самого инструмента: расширения для редакторов, биндинги для Python, песочница на WASM, сайт с документацией, пакеты под разные экосистемы. ИИ освободил мыслительные ресурсы для проработки UX - сообщений об ошибках, настроек форматировщика по умолчанию, интуитивности CLI - всего того, что отличает прижившийся инструмент от одноразовой поделки.
Где ИИ навредил
Петля зависимости. Психология игрового автомата: отправить промпт, дождаться ответа, получить дофаминовый укол и захотеть "ещё один промпт". Усталость только раскручивает этот цикл: в уставшем состоянии формулируешь размыто, размытые промпты дают плохой результат, плохой результат утомляет ещё сильнее. По словам Маганти, такая петля может работать медленнее ручного кодинга, но выйти из неё психологически трудно. Это наименее обсуждаемый сбойный сценарий при разработке с ИИ.
Потеря ментальной модели. Когда большую часть кода пишет ИИ, перестаёшь понимать, какие функции что вызывают, какие мелкие решения накопились в системе и где проходят границы модулей. Общение с ИИ деградирует: вместо "измени FooClass, чтобы он делал X" говоришь "поменяй ту штуку, которая делает Bar", и агенту приходится гадать. Способ борьбы: вычитывать код сразу после генерации и активно обдумывать альтернативы.
Откладывание архитектурных решений. Поскольку рефакторинг казался дешёвым, Маганти откладывал выбор архитектуры на потом. Но эта отсрочка подтачивала ясность мышления: кодовая база оставалась запутанной, даже если переделка казалась бесплатной. Первая фаза наглядно это показала: решения по архитектуре на раннем этапе колоссально ускорили бы выход на рабочий результат.
Ложное чувство безопасности от тестов. Более 500 сгенерированных тестов создали иллюзию надёжности. Тесты отлавливают предсказуемые граничные случаи. Без выверенной архитектуры непредвиденные баги будут лезть бесконечно. В прототипе первой фазы было полно тестов, но его всё равно пришлось полностью переписывать. Тесты необходимы, но недостаточны: несущей конструкцией остаётся архитектура.
Отсутствие исторического контекста. ИИ видит текущее состояние кодовой базы, но не чувствует, как эволюционировали API, почему принимались решения и чему научили прошлые ошибки. Из-за этого страдает последовательность дизайна API и повторяются старые промахи. Опытные инженеры держат этот контекст в голове сами; ИИ же требует исчерпывающей документации, которую люди писать не будут.
Иерархия экспертизы
Маганти выделяет четыре зоны эффективности ИИ:
- Глубокая экспертиза (правила парсера) - ИИ показывает себя блестяще. Вы мгновенно оцениваете код, ловите ошибки до коммита, быстро итерируетесь. Лучший сценарий.
- Понятная потребность при нехватке знаний (Wadler-Lindig) - ИИ полезен при активной работе с ним. Нельзя пассивно принимать результаты: нужно оценивать направление и учиться по ходу дела.
- Непонимание того, что нужно (архитектура на раннем этапе) - ИИ заводит в тупики, сжирающие недели. Худшая трата времени при работе с ИИ.
- Отсутствие объективно проверяемого ответа (дизайн API) - ИИ терпит полный провал. Проектирование требует вкуса. Дни уходили на исправление придуманных ИИ API, которые технически "работали", но были неудобны в использовании.
Фреймворк относительности
Локальный код (функции, классы) выглядит ньютоновским - прямолинейным, тестируемым, ИИ с ним справляется. Если отдалиться, архитектура искривляется подобно пространству-времени: локальная корректность не гарантирует глобальной согласованности. Понимание того, где именно вы находитесь на этой шкале, определяет, станет ли ИИ ускорителем или ловушкой.
"ИИ - невероятный мультипликатор для реализации, но опасная замена проектированию".
Связи
Это самый подробный в этой базе знаний рассказ от первого лица о переходе от vibe-coding'а к дисциплине. В cult-of-vibe-coding тот же тезис приводится снаружи (критика команды Claude со стороны Коэна); Маганти же прожил этот опыт сам и описал конкретные сбои.
Петля зависимости и утрата ментальной модели - это сбои, предотвращать которые как раз и призван подход human-in-the-loop. Хотя концепцию HITL обычно подают как механизм безопасности, здесь "человек в контуре" защищает качество кода за счёт сохранения понимания архитектуры.
Наблюдение о ложном чувстве безопасности от тестов перекликается с логикой byzantine-fault: тесты выступают валидатором, но ловят только заранее предусмотренные ошибки. Архитектурная целостность - это другой тип корректности, который невозможно полностью подтвердить никаким набором тестов.
Выступление Брайана Кантрилла "The Peril of Laziness Lost" даёт имя тому, что пошло не так на первой фазе: утрата лени. Без ограничений человеческого времени, заставляющих упрощать решения, LLM выдала слоёный пирог из мусора - ровно то, с чем столкнулся Маганти, пока на второй фазе не переключился на разработку под управлением архитектора.
Тезис "проектирование нельзя делегировать" - это выстраданная Маганти переформулировка сущностной сложности Брукса: спецификация, проектирование и тестирование концептуальной структуры - вот где кроется настоящая сложность, и LLM не сделает это за вас. Джеймс Беннетт доказывает то же самое теоретически на данных DORA/CircleCI/METR.
agentic-coding-fatigue прямо называет петлю зависимости: первая фаза у Маганти - это как раз описанный 0xsid gacha-режим, а дневной лимит в четыре-пять часов объясняет, почему этот азартный вариант создавал ощущение продуктивности, пока втихую выжигал силы.
back-to-coding-by-hand - это сокращённая версия финала первой фазы, только там автор полностью отказался от ИИ, вместо того чтобы переписать всё заново вместе с ним.
- Database Design and Implementation
- acai.sh
- lightroom-cc-on-linux
- 1Password — What We Learned Using AI Agents to Refactor a Monolith
- A Voice From Nowhere
- Acceptance Criteria IDs (ACIDs)
- Agentic Coding is Burning Me Out
- Agentic Coding is a Trap
- My AI-Assisted Workflow
- The AI Great Leap Forward
- Anti-LLM Discourse
- I'm Going Back to Coding by Hand (Ask HN)
- A recent experience with ChatGPT 5.5 Pro (Gowers)
- Clean Code in the Age of Coding Agents
- Don't Outsource Learning
- You'll Lose Your Job in 2027 — Elena Verna
- I don't want your PRs anymore
- IngoDB — AI-Native Adaptive Database
- Codex-maxxing
- LLM-assisted mathematical research
- Let's talk about LLMs (Bennett)
- No Silver Bullet
- OSS sustainability
- The Peril of Laziness Lost
- You Should Read "Programming as Theory Building"
- Programming as Theory Building
- Programming still sucks (stvn)
- Defining AI Psychosis, Part 2: Prolific AI Psychosis
- Vibe-coding a memory tool into a 130-year-old open problem
- AI Agents and the Refactoring That Never Happens
- Vibe Coding and Agentic Engineering Are Getting Closer Than I'd Like
- Skill atrophy and the supervision paradox
- Specsmaxxing — Acceptance Criteria as the Primary Artifact