Практические истины Джоэла Спольски про тесты, найм и простоту, переосмысленные для AI-разработки, где код дешев, а ошибки дороги.
AI заметно упростил сам акт написания кода. Теперь можно быстро набросать сервис, экран приложения или интеграцию, просто объяснив задачу словами. Но ответственность за результат никуда не делась: пользователю все равно, кто написал баг, человек или модель.
Скорость стала новым источником риска. Когда изменения делаются десятками за день, растет шанс тихих поломок: где-то поменяли формат данных, где-то пропали проверки, где-то «улучшили» логику и сломали крайний случай. Код появляется быстро, а понимание того, как он ведет себя во всех ситуациях, само не появляется.
Поэтому практические истины Джоэла Спольски звучат даже актуальнее. Это не ностальгия по «старой школе», а защитные правила в мире, где код дешевый, а ошибки дорогие.
Полезнее всего пересмотреть четыре идеи:
Речь о практиках, а не о культе инструментов. Можно писать в IDE, можно в чате, можно в vibe-coding платформе вроде TakProsto, но правила те же: фиксируем требования, проверяем изменения, упрощаем, заранее решаем, кто отвечает за продакшн-результат.
С появлением AI и vibe-coding код стал почти расходником. Черновик можно получить за минуты, попробовать три варианта, выкинуть два и переписать третий. Это помогает быстрее искать форму продукта и точнее понимать, что действительно нужно пользователю.
Но корректность не подешевела. Правильность поведения системы проверяется медленно, и цена ошибки часто выше цены разработки. Особенно когда приложение уже живет: в нем есть пользователи, деньги и данные.
Чаще всего все ломается не в «середине», а на краях, где мелочи превращаются в инциденты: на границах данных (пустые поля, отрицательные суммы, разные форматы), в переходах состояний (повторный клик, отмена, повторная отправка), в интеграциях (таймауты, частичные ответы, разные версии API), в платежах и биллинге (дубли, возвраты, расхождения) и в правах доступа (кто что видит и кто что может менять).
AI усиливает и хорошие, и плохие привычки команды. Если принято «лишь бы работало на демо», AI ускорит накопление случайной логики и тихих дыр. Если принято уточнять требования, фиксировать ожидания и проверять гипотезы тестами, AI станет ускорителем качества: он быстрее пишет заготовки, но команда решает, что считается правильным.
Простой пример: вы за вечер собрали в TakProsto админку для скидок. AI легко добавит поля и кнопки, но корректность здесь живет в правилах: кто может создавать скидки, суммируются ли они, как работает срок действия, что будет при возврате платежа. Эти ответы не появляются автоматически из кода. Их нужно сформулировать, а потом заставить систему доказать, что она им следует.
Полезный переключатель мышления такой: код можно переписать, а доверие пользователей и чистые данные переписываются намного дороже.
Когда часть кода пишет AI, появляется опасная иллюзия: раз оно сгенерировалось быстро и «похоже на правду», значит будет работать. На практике регрессии возникают тихо: вы меняете один запрос или промпт, а ломается совсем другой угол.
AI часто делает «разумные» допущения. Например, меняет формат даты, добавляет лишнюю валидацию или переименовывает поле в JSON. На демо все красиво, а в реальном потоке это превращается в баги, которые сложно отловить глазами.
Минимальный набор тестов помогает держать систему в руках даже при быстрой разработке (хоть в TakProsto, хоть где угодно):
Начинать почти всегда стоит с того, что больнее всего ломать: деньги и биллинг, безопасность, данные пользователей, а также ключевые потоки вроде регистрации, входа и оформления заказа.
Чтобы тесты не превратились в вечную перепись, пишите их «по поведению», а не по реализации. Проверяйте результат и контракт, а не внутренние шаги. Фиксируйте входные данные, избегайте случайностей, давайте тестам понятные имена. Хороший тест легко объяснить словами: «если пользователь без прав, то не может увидеть чужие данные». Если объяснить сложно, поддерживать будет еще сложнее.
Если код написал AI, ревью становится не менее важным, а более важным. Модель не знает ваших договоренностей: как вы именуете сущности, где храните бизнес-логику, что считается приемлемым риском. Она также не чувствует последствий. Если в проде упадет платеж или сломается миграция, отвечать будет команда.
Правило простое: ответственность всегда у людей. Ревьюер не ставит печать на «красивый код». Он подтверждает, что изменение безопасно и соответствует цели.
Чтобы ревью было быстрым, делайте изменения маленькими и с понятной задачей. В vibe-coding легко попросить «добавь еще вот это» и получить огромный дифф, который никто не переварит. Лучше дробить работу на шаги с четкими критериями приемки.
Что стоит проверять вручную, даже если AI уверенно «все учел»:
AI можно использовать и в ревью, но не как судью. Попросите его сыграть роль «адвоката дьявола»: найти несостыковки с описанием задачи, предложить крайние сценарии, указать на места, где обработка ошибок выглядит хрупко.
Если вы работаете в TakProsto и можете быстро откатываться снапшотами, помогает простой порядок: сначала ревью на уровне намерения (что меняем и почему), затем короткий просмотр кода, затем пробный прогон критических сценариев. Так вы держите скорость, но не отдаете контроль модели.
Правило Спольски не устарело: простые системы ломаются реже и чинятся быстрее. В AI-разработке это видно особенно ярко. Код генерируется быстро, но каждое лишнее усложнение остается с вами надолго: в поддержке, тестах, релизах и разборе инцидентов.
AI провоцирует «умный» дизайн там, где он не нужен. Модель охотно добавляет абстракции «на будущее», плодит слои (сервисы, фасады, адаптеры), тянет зависимости ради одного удобного метода и предлагает универсальные решения вместо конкретных. Проект выглядит солидно, но превращается в лабиринт.
Ненужная сложность обычно заметна по трем признакам. Первое: это трудно объяснить на пальцах. Второе: это трудно протестировать (тест требует поднять половину системы). Третье: это трудно откатить (любой фикс тянет миграции, новые конфиги и каскад изменений).
Перед тем как просить AI написать код, сформулируйте самую простую версию решения в 5-7 предложениях. Детали добавляйте только если есть причина: производительность, безопасность, реальная боль пользователей.
Короткий чек перед тем, как принимать сгенерированную архитектуру:
Например, вы собираете внутренний сервис заявок в vibe-coding платформе вроде TakProsto. AI предложит события, очереди, отдельный сервис уведомлений и сложную модель статусов. Начните с одного API, одной таблицы и простых статусов. Когда появится реальная очередь и реальные задержки, тогда и добавляйте асинхронность.
Когда AI помогает писать код, скорость печати перестает быть преимуществом. Ценится другое: ясное мышление, аккуратность и умение доводить работу до состояния, за которое не стыдно.
Ищите людей, которые умеют формулировать требования простыми словами, замечают риски раньше, чем они станут инцидентом, и не сдают задачу, пока не проверили результат. В AI-разработке особенно заметна разница между теми, кто «генерирует», и теми, кто отвечает за качество.
На собеседовании лучше проверять не знание модных инструментов, а практику принятия решений. Дайте кандидату небольшой сценарий с багом и попросите рассуждать вслух: что он уточнит, что проверит, что сделает первым.
Полезные форматы задач для интервью:
Коммуникация и письмо стали критичнее, потому что промпты, спецификации и договоренности теперь напрямую влияют на результат. Если команда использует vibe-coding платформы вроде TakProsto, качество начинается с того, как вы описали задачу, ограничения, критерии готовности и что считаете «нормальным» поведением.
Частая ошибка найма: взять человека, который быстро производит много кода, но не умеет проверять и сомневаться. Простой маркер: спросите, как он доказывает, что функция работает, и что делает, когда не уверен. Если ответ сводится к «AI сказал, значит так», это риск для проекта.
AI ускоряет набор текста, но не снимает ответственность за результат. Поэтому идеи Спольски лучше всего внедрять не как лозунги, а как маленькие правила команды, которые повторяются каждый день.
Попробуйте простой процесс на неделю и закрепите его в привычках:
Чтобы это не превратилось в бюрократию, держите метрики минимальными:
Если числа улучшаются, процесс работает. Если ухудшаются, сначала упрощайте изменения и усиливайте проверку ядра, а не добавляйте новые «правила ради правил».
Главная ловушка в том, что скорость легко перепутать с прогрессом. Коммитов много, экран постоянно меняется, но продукт не становится устойчивее: баги всплывают снова, требования плавают, а команда не может уверенно сказать, что именно уже работает.
Вторая частая ошибка - слепо доверять ответам модели. AI часто звучит уверенно даже когда ошибается, и проблемы особенно плохо видны на граничных случаях: пустые значения, большие числа, нестабильная сеть, частичные права доступа, неожиданные форматы данных.
Есть и более «тихие» промахи, которые накапливают долг:
Отдельная ошибка - считать, что если код сгенерирован, то ответственность размылась. На деле ответственность только усиливается: кто-то должен подтвердить, что поведение верное, а не просто «похоже на правду».
Небольшой пример: вы быстро собрали прототип в vibe-coding, и он уже радует демо. Если не сделать снимок рабочей версии и не договориться о шаге отката, следующая «умная» правка может сломать регистрацию или оплату, и вы потратите день на поиск того самого удачного состояния. В TakProsto для этого как раз есть snapshots и rollback, но сама привычка ставить безопасные точки важнее любого инструмента.
Перед тем как нажать кнопку релиза, полезно пройтись по короткой проверке. Код можно нагенерировать быстро, но последствия ошибок все такие же дорогие.
Потратьте 10 минут и честно ответьте:
Этот список особенно важен, когда вы работаете с AI-помощником или vibe-coding. Модель легко предложит сложную конструкцию, которая выглядит умно, но потом ломается на реальных данных. Если вы не можете объяснить решение кратко, скорее всего, вы не сможете и поддерживать его спокойно.
Небольшой пример: вы добавили кнопку «Вернуть платеж». Перед релизом проверьте не только «кнопка нажимается», а что будет при двойном клике, при таймауте, при повторном запросе и при недостаточных правах. И убедитесь, что откат не испортит историю транзакций.
Если вы делаете проект в TakProsto, удобно заранее договориться о критериях приемки в planning mode, а перед выкладкой проверить, что есть точка возврата через снапшоты.
Небольшая компания по сервисному обслуживанию просит мини-CRM и личный кабинет для клиентов. Нужно за 2 недели: заявки, статусы, комментарии мастеров, пара отчетов для руководства. Бюджет ограничен, а владельцу важнее начать работать, чем получить идеальную систему.
В vibe-coding это реально. Например, в TakProsto можно быстро собрать каркас: экран списка заявок, карточку заявки, формы создания клиента и заявки, простую админку, базовые отчеты по периодам. AI хорошо помогает с однотипными формами, таблицами, фильтрами и черновой бизнес-логикой.
Проблемы начинаются не в UI, а на краях системы. Чаще всего всплывают такие риски:
Чтобы прототип не превратился в вечный пожар, полезно идти по-спольски: сначала простые правила, потом расширение. Выбирают 5-7 главных сценариев (создать заявку, сменить статус, клиент вошел и увидел только свое, менеджер сформировал отчет) и пишут к ним минимальные автотесты и проверки данных. Затем добавляют новые функции только после того, как базовые сценарии стабильно проходят.
И еще одно правило: обязательный откат. Если платформа дает снапшоты и rollback, это становится частью ритуала релиза: перед изменениями делаем снимок, после релиза проверяем сценарии, при проблеме откатываемся за минуты, а не за ночь.
Готовность заметна по поведению продукта: ключевые сценарии повторяются без сюрпризов, регрессий мало, а релизы предсказуемы по времени и результату.
Начните с общего договора в команде. AI помогает писать код быстрее, но цена ошибки не падает. Важнее всего сделать процесс понятным: что считается «готово», кто проверяет, и как откатиться, если что-то пошло не так.
Соберите короткий набор правил и закрепите их в одном месте. Пусть это будет живой документ, который можно дополнять после каждого инцидента или сложного релиза:
Дальше выделите ядро продукта: платежи, авторизация, критичные расчеты, важные интеграции. Именно это защищайте тестами и более строгим ревью. Для всего остального допускайте больше скорости, но с ограничителями: небольшие изменения, явные проверки, понятные метрики.
Обратимость должна стать привычкой:
Если нужен быстрый старт, можно попробовать vibe-coding в TakProsto: вы описываете задачу в чате, а платформа помогает собрать веб-, серверное или мобильное приложение. Для аккуратной работы с изменениями помогают planning mode, snapshots и откат. А когда нужно больше контроля, можно экспортировать исходники и развернуть проект на своем домене.
Главный критерий успеха простой: скорость выросла, а количество «сюрпризов» после релиза не выросло.
Потому что AI ускорил написание кода, но не сделал ошибки дешевле. Пользователь не различает, кто написал баг — человек или модель.
Самое ценное в идеях Спольски — фокус на проверяемости, простоте, ответственности и повторяемом процессе. Это как раз то, что удерживает качество, когда изменения делаются очень быстро.
Сначала закройте то, что «дороже всего ломать»:
Дальше расширяйте покрытие не «по списку», а по реальным инцидентам и рискам.
Возьмите за привычку проверять «края», где чаще всего рвется:
null, нули, большие числаПрактика: перед мерджем попросите AI перечислить 10 крайних сценариев, а вы выберите 3–5 самых опасных и добавьте проверки (тестами или обязательным ручным прогоном).
Нет. Ревью становится даже важнее, потому что модель не знает ваших договоренностей и не несет последствий.
Ревьюер подтверждает не «красоту», а безопасность изменения:
Дробите работу на маленькие изменения с понятной задачей и явной проверкой.
Удобный шаблон для каждого изменения:
Выбирайте решение, которое можно объяснить «на пальцах» и покрыть тестами без поднятия половины системы.
Короткий само-чек:
Если на эти вопросы сложно ответить, скорее всего, AI добавил лишние слои и зависимости.
Проверяйте не «скорость печати», а мышление и привычки качества:
Хороший формат — дать небольшой сценарий с ошибкой и попросить рассуждать вслух: что проверит первым и почему.
Сделайте откат «по умолчанию» частью процесса.
Если вы в TakProsto, практично выглядит так:
Главная цель — чтобы путь назад был короче и надежнее, чем путь вперед.
Сформулируйте задачу как короткую спецификацию:
В TakProsto это удобно фиксировать в planning mode: сначала договориться о поведении, а уже потом генерировать и принимать код.
Достаточно 2–3 простых метрик, которые отражают боль:
Если метрики ухудшаются, обычно помогает не усложнение регламента, а обратное: меньше размер изменений, больше проверок ядра (платежи, доступы, данные), яснее критерии приемки.
Так дифф легче переварить, а ошибки проще локализовать.