Практические истины Джоэла Спольски в эпоху AI-разработки

Что поменялось с AI, а что осталось прежним

AI заметно упростил сам акт написания кода. Теперь можно быстро набросать сервис, экран приложения или интеграцию, просто объяснив задачу словами. Но ответственность за результат никуда не делась: пользователю все равно, кто написал баг, человек или модель.

Скорость стала новым источником риска. Когда изменения делаются десятками за день, растет шанс тихих поломок: где-то поменяли формат данных, где-то пропали проверки, где-то «улучшили» логику и сломали крайний случай. Код появляется быстро, а понимание того, как он ведет себя во всех ситуациях, само не появляется.

Поэтому практические истины Джоэла Спольски звучат даже актуальнее. Это не ностальгия по «старой школе», а защитные правила в мире, где код дешевый, а ошибки дорогие.

Полезнее всего пересмотреть четыре идеи:

• Проверяемость важнее уверенности: если это нельзя подтвердить тестом или проверкой, это пока предположение.
• Простота важнее «умности»: чем проще решение, тем меньше шансов, что AI принесет лишние зависимости и скрытые условия.
• Качество команды видно по мышлению: ценятся те, кто задает правильные вопросы, а не те, кто быстрее печатает.
• Процесс важнее героизма: надежность рождается из повторяемых практик, а не из одного удачного промпта.

Речь о практиках, а не о культе инструментов. Можно писать в IDE, можно в чате, можно в vibe-coding платформе вроде TakProsto, но правила те же: фиксируем требования, проверяем изменения, упрощаем, заранее решаем, кто отвечает за продакшн-результат.

Код стал дешевым, но корректность - нет

С появлением AI и vibe-coding код стал почти расходником. Черновик можно получить за минуты, попробовать три варианта, выкинуть два и переписать третий. Это помогает быстрее искать форму продукта и точнее понимать, что действительно нужно пользователю.

Но корректность не подешевела. Правильность поведения системы проверяется медленно, и цена ошибки часто выше цены разработки. Особенно когда приложение уже живет: в нем есть пользователи, деньги и данные.

Чаще всего все ломается не в «середине», а на краях, где мелочи превращаются в инциденты: на границах данных (пустые поля, отрицательные суммы, разные форматы), в переходах состояний (повторный клик, отмена, повторная отправка), в интеграциях (таймауты, частичные ответы, разные версии API), в платежах и биллинге (дубли, возвраты, расхождения) и в правах доступа (кто что видит и кто что может менять).

AI усиливает и хорошие, и плохие привычки команды. Если принято «лишь бы работало на демо», AI ускорит накопление случайной логики и тихих дыр. Если принято уточнять требования, фиксировать ожидания и проверять гипотезы тестами, AI станет ускорителем качества: он быстрее пишет заготовки, но команда решает, что считается правильным.

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

Полезный переключатель мышления такой: код можно переписать, а доверие пользователей и чистые данные переписываются намного дороже.

Тестирование: меньше веры, больше проверок

Когда часть кода пишет AI, появляется опасная иллюзия: раз оно сгенерировалось быстро и «похоже на правду», значит будет работать. На практике регрессии возникают тихо: вы меняете один запрос или промпт, а ломается совсем другой угол.

AI часто делает «разумные» допущения. Например, меняет формат даты, добавляет лишнюю валидацию или переименовывает поле в JSON. На демо все красиво, а в реальном потоке это превращается в баги, которые сложно отловить глазами.

Минимальный набор тестов помогает держать систему в руках даже при быстрой разработке (хоть в TakProsto, хоть где угодно):

• Юнит-тесты для правил и функций, где важна логика (расчеты, валидация, права).
• Интеграционные тесты для связок (API + база, авторизация + роли, очереди).
• E2E тесты для 2-3 самых критичных пользовательских сценариев.

Начинать почти всегда стоит с того, что больнее всего ломать: деньги и биллинг, безопасность, данные пользователей, а также ключевые потоки вроде регистрации, входа и оформления заказа.

Чтобы тесты не превратились в вечную перепись, пишите их «по поведению», а не по реализации. Проверяйте результат и контракт, а не внутренние шаги. Фиксируйте входные данные, избегайте случайностей, давайте тестам понятные имена. Хороший тест легко объяснить словами: «если пользователь без прав, то не может увидеть чужие данные». Если объяснить сложно, поддерживать будет еще сложнее.

Код-ревью и ответственность: кто отвечает за результат

Если код написал AI, ревью становится не менее важным, а более важным. Модель не знает ваших договоренностей: как вы именуете сущности, где храните бизнес-логику, что считается приемлемым риском. Она также не чувствует последствий. Если в проде упадет платеж или сломается миграция, отвечать будет команда.

Правило простое: ответственность всегда у людей. Ревьюер не ставит печать на «красивый код». Он подтверждает, что изменение безопасно и соответствует цели.

Чтобы ревью было быстрым, делайте изменения маленькими и с понятной задачей. В vibe-coding легко попросить «добавь еще вот это» и получить огромный дифф, который никто не переварит. Лучше дробить работу на шаги с четкими критериями приемки.

Что стоит проверять вручную, даже если AI уверенно «все учел»:

• Граничные случаи и пустые данные (0, null, пустые списки, большие числа).
• Ошибки и ретраи: что увидит пользователь, что попадет в логи.
• Безопасность: права доступа, утечки данных, опасные запросы.
• Миграции и совместимость: что будет со старой схемой и данными.
• Побочные эффекты: кеш, очереди, письма, списания.

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

Если вы работаете в TakProsto и можете быстро откатываться снапшотами, помогает простой порядок: сначала ревью на уровне намерения (что меняем и почему), затем короткий просмотр кода, затем пробный прогон критических сценариев. Так вы держите скорость, но не отдаете контроль модели.

Простота как защита от AI-сложности

Правило Спольски не устарело: простые системы ломаются реже и чинятся быстрее. В AI-разработке это видно особенно ярко. Код генерируется быстро, но каждое лишнее усложнение остается с вами надолго: в поддержке, тестах, релизах и разборе инцидентов.

AI провоцирует «умный» дизайн там, где он не нужен. Модель охотно добавляет абстракции «на будущее», плодит слои (сервисы, фасады, адаптеры), тянет зависимости ради одного удобного метода и предлагает универсальные решения вместо конкретных. Проект выглядит солидно, но превращается в лабиринт.

Ненужная сложность обычно заметна по трем признакам. Первое: это трудно объяснить на пальцах. Второе: это трудно протестировать (тест требует поднять половину системы). Третье: это трудно откатить (любой фикс тянет миграции, новые конфиги и каскад изменений).

Практика: сначала простая версия

Перед тем как просить AI написать код, сформулируйте самую простую версию решения в 5-7 предложениях. Детали добавляйте только если есть причина: производительность, безопасность, реальная боль пользователей.

Короткий чек перед тем, как принимать сгенерированную архитектуру:

• Можно ли описать это одной диаграммой и тремя сущностями?
• Можно ли покрыть ключевую логику юнит-тестами без «поднятия всего»?
• Можно ли удалить модуль и ничего не сломать, кроме его функции?
• Есть ли одна очевидная точка, где лежит бизнес-правило?
• Можно ли откатить релиз за минуты?

Например, вы собираете внутренний сервис заявок в vibe-coding платформе вроде TakProsto. AI предложит события, очереди, отдельный сервис уведомлений и сложную модель статусов. Начните с одного API, одной таблицы и простых статусов. Когда появится реальная очередь и реальные задержки, тогда и добавляйте асинхронность.

Найм и команда: ценятся не пальцы, а голова

Когда AI помогает писать код, скорость печати перестает быть преимуществом. Ценится другое: ясное мышление, аккуратность и умение доводить работу до состояния, за которое не стыдно.

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

На собеседовании лучше проверять не знание модных инструментов, а практику принятия решений. Дайте кандидату небольшой сценарий с багом и попросите рассуждать вслух: что он уточнит, что проверит, что сделает первым.

Полезные форматы задач для интервью:

• Разбор бага по описанию: гипотезы, шаги проверки, минимальный фикс.
• Чтение чужого кода: что опасно, где неочевидные зависимости, что улучшить без переписывания.
• Приоритизация тестов: что тестировать в первую очередь, если времени мало, и почему.
• Мини-спецификация: написать 10-15 строк требований так, чтобы по ним можно было работать.
• Оценка рисков релиза: что может пойти не так и как это поймать заранее.

Коммуникация и письмо стали критичнее, потому что промпты, спецификации и договоренности теперь напрямую влияют на результат. Если команда использует vibe-coding платформы вроде TakProsto, качество начинается с того, как вы описали задачу, ограничения, критерии готовности и что считаете «нормальным» поведением.

Частая ошибка найма: взять человека, который быстро производит много кода, но не умеет проверять и сомневаться. Простой маркер: спросите, как он доказывает, что функция работает, и что делает, когда не уверен. Если ответ сводится к «AI сказал, значит так», это риск для проекта.

Как внедрить подход Спольски в AI-проекте - пошагово

AI ускоряет набор текста, но не снимает ответственность за результат. Поэтому идеи Спольски лучше всего внедрять не как лозунги, а как маленькие правила команды, которые повторяются каждый день.

Попробуйте простой процесс на неделю и закрепите его в привычках:

• Определите ядро продукта. Выберите 1-2 ключевых пользовательских сценария (например, регистрация и оплата) и запишите критерии приемки простыми фразами: что пользователь видит, что считается успехом, какие ошибки допустимы.
• Договоритесь, как выглядят изменения. Делайте маленькие PR, пишите понятные сообщения к коммитам, добавьте короткий чек-лист перед мерджем: «понятно ли, зачем это», «не ломает ли сценарии», «есть ли тест или ручная проверка».
• Соберите тестовый минимум. Автотестами закройте самое важное, а для остального заведите шаблон ручной проверки. Ручная проверка должна быть одинаковой у всех, а не «каждый проверил как привык».
• Встройте откат по умолчанию. Любое изменение должно быть обратимым: фича-флаг, конфигурация, отдельный шаг выката. Если вы работаете в TakProsto, удобно опираться на snapshots и rollback как на обязательную страховку.
• Сделайте качество видимым. Раз в неделю смотрите на 2-3 простые цифры и обсуждайте их без поиска виноватых.

Чтобы это не превратилось в бюрократию, держите метрики минимальными:

• баги после релиза за неделю
• среднее время до исправления
• сколько раз пришлось откатывать изменения

Если числа улучшаются, процесс работает. Если ухудшаются, сначала упрощайте изменения и усиливайте проверку ядра, а не добавляйте новые «правила ради правил».

Типичные ошибки при AI-разработке

Главная ловушка в том, что скорость легко перепутать с прогрессом. Коммитов много, экран постоянно меняется, но продукт не становится устойчивее: баги всплывают снова, требования плавают, а команда не может уверенно сказать, что именно уже работает.

Вторая частая ошибка - слепо доверять ответам модели. AI часто звучит уверенно даже когда ошибается, и проблемы особенно плохо видны на граничных случаях: пустые значения, большие числа, нестабильная сеть, частичные права доступа, неожиданные форматы данных.

Есть и более «тихие» промахи, которые накапливают долг:

• Тесты пишутся после того, как все уже «почти готово», и проверяют второстепенное, а не ключевые пользовательские потоки.
• Большие правки вливаются одним куском, без промежуточных точек, где можно остановиться и оценить, стало ли лучше.
• План отката отсутствует: откатить изменения сложно, потому что все перемешано.
• Архитектура разрастается незаметно: новые слои, абстракции и «универсальные» модули появляются просто потому, что AI так предложил.

Отдельная ошибка - считать, что если код сгенерирован, то ответственность размылась. На деле ответственность только усиливается: кто-то должен подтвердить, что поведение верное, а не просто «похоже на правду».

Небольшой пример: вы быстро собрали прототип в vibe-coding, и он уже радует демо. Если не сделать снимок рабочей версии и не договориться о шаге отката, следующая «умная» правка может сломать регистрацию или оплату, и вы потратите день на поиск того самого удачного состояния. В TakProsto для этого как раз есть snapshots и rollback, но сама привычка ставить безопасные точки важнее любого инструмента.

Короткий чек-лист перед релизом

Перед тем как нажать кнопку релиза, полезно пройтись по короткой проверке. Код можно нагенерировать быстро, но последствия ошибок все такие же дорогие.

5 вопросов, которые экономят нервы

Потратьте 10 минут и честно ответьте:

• Есть ли у фичи один понятный сценарий и критерии приемки, по которым любой в команде скажет: сделано или нет?
• Проверены ли самые дорогие провалы: платежи, права доступа, персональные данные, удаление и изменение записей?
• Есть ли быстрый откат: снапшот, rollback или хотя бы понятная инструкция, как вернуть прошлую версию без ручной паники?
• Ясно ли, что произойдет при ошибке: что увидит пользователь, что попадет в логи, и какой текст сообщения не будет вводить в заблуждение?
• Можете ли вы объяснить выбранное решение простыми словами за 2 минуты, без оправданий и длинных цепочек условий?

Этот список особенно важен, когда вы работаете с AI-помощником или vibe-coding. Модель легко предложит сложную конструкцию, которая выглядит умно, но потом ломается на реальных данных. Если вы не можете объяснить решение кратко, скорее всего, вы не сможете и поддерживать его спокойно.

Небольшой пример: вы добавили кнопку «Вернуть платеж». Перед релизом проверьте не только «кнопка нажимается», а что будет при двойном клике, при таймауте, при повторном запросе и при недостаточных правах. И убедитесь, что откат не испортит историю транзакций.

Если вы делаете проект в TakProsto, удобно заранее договориться о критериях приемки в planning mode, а перед выкладкой проверить, что есть точка возврата через снапшоты.

Пример из жизни: быстрый прототип, который не стыдно поддерживать

Небольшая компания по сервисному обслуживанию просит мини-CRM и личный кабинет для клиентов. Нужно за 2 недели: заявки, статусы, комментарии мастеров, пара отчетов для руководства. Бюджет ограничен, а владельцу важнее начать работать, чем получить идеальную систему.

В vibe-coding это реально. Например, в TakProsto можно быстро собрать каркас: экран списка заявок, карточку заявки, формы создания клиента и заявки, простую админку, базовые отчеты по периодам. AI хорошо помогает с однотипными формами, таблицами, фильтрами и черновой бизнес-логикой.

Проблемы начинаются не в UI, а на краях системы. Чаще всего всплывают такие риски:

• Права доступа: клиент видит чужие заявки, менеджер может удалить важные данные.
• Удаление и восстановление: случайно стерли клиента, и все связи распались.
• Импорт: загрузили CSV, а форматы дат и телефонов «поехали».
• Уведомления: письма ушли не тем или ушли дважды.
• Платежи: статус оплаты не совпал с реальностью.

Чтобы прототип не превратился в вечный пожар, полезно идти по-спольски: сначала простые правила, потом расширение. Выбирают 5-7 главных сценариев (создать заявку, сменить статус, клиент вошел и увидел только свое, менеджер сформировал отчет) и пишут к ним минимальные автотесты и проверки данных. Затем добавляют новые функции только после того, как базовые сценарии стабильно проходят.

И еще одно правило: обязательный откат. Если платформа дает снапшоты и rollback, это становится частью ритуала релиза: перед изменениями делаем снимок, после релиза проверяем сценарии, при проблеме откатываемся за минуты, а не за ночь.

Готовность заметна по поведению продукта: ключевые сценарии повторяются без сюрпризов, регрессий мало, а релизы предсказуемы по времени и результату.

Следующие шаги: как применить это на вашем проекте

Начните с общего договора в команде. AI помогает писать код быстрее, но цена ошибки не падает. Важнее всего сделать процесс понятным: что считается «готово», кто проверяет, и как откатиться, если что-то пошло не так.

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

• Как оформляем изменения: маленькие PR, понятные названия, описание риска.
• Как тестируем: минимум для каждого изменения, что запускаем перед релизом.
• Как принимаем: кто имеет право мержить, когда нужен второй взгляд.
• Как работаем с AI: что можно доверять, что всегда перепроверяем.
• Как фиксируем решения: кратко, но так, чтобы через месяц было ясно «почему так».

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

Обратимость должна стать привычкой:

• Перед крупным изменением делайте точку возврата.
• Выпускайте небольшими порциями и наблюдайте за эффектом.
• Держите путь назад короче, чем путь вперед.

Если нужен быстрый старт, можно попробовать vibe-coding в TakProsto: вы описываете задачу в чате, а платформа помогает собрать веб-, серверное или мобильное приложение. Для аккуратной работы с изменениями помогают planning mode, snapshots и откат. А когда нужно больше контроля, можно экспортировать исходники и развернуть проект на своем домене.

Главный критерий успеха простой: скорость выросла, а количество «сюрпризов» после релиза не выросло.