Основные истины Joel Spolsky для разработки с поддержкой ИИ

Почему эти истины всё ещё важны, когда ИИ быстро пишет код

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

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

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

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

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

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

Тестирование остаётся узким местом, и это хорошо

Когда ИИ генерирует фичу за минуты, появляется соблазн считать тестирование той медленной частью, от которой нужно избавиться. Точка Спольски всё ещё верна: медленная часть — это то место, где живёт правда. Код легко произвести. Правильное поведение — нет.

Полезный сдвиг — рассматривать тесты как проверяемые требования. Если вы не можете описать ожидаемое поведение в проверяемом виде, вы ещё не завершили размышления. В работе с ИИ это важно даже больше, потому что модель может уверенно выдать что‑то чуть неверное.

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

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

Делайте ошибки информативными. Упавший тест должен сказать, что сломалось, а не отправлять на поиски сокровищ. Держите тесты маленькими, называйте их как предложения и делайте сообщения об ошибках конкретными.

Быстрый пример

Предположим, вы создаёте простое приложение «заметки команды» при помощи ИИ. CRUD‑экраны появляются быстро. Риск корректности — не интерфейс. Риск в контроле доступа и правилах данных: пользователь не должен видеть заметки другой команды, правки не должны перезаписывать более новые изменения, удаление заметки не должно оставлять сиротские вложения. Тесты, которые закрепляют эти правила, будут казаться узким местом, но они же и ваша страховочная сеть.

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

Простота побеждает хитрость, особенно с ИИ в цепочке

Одна из самых надёжных истин: простой код побеждает хитрый. ИИ делает соблазнительным принимать вычурные абстракции, потому что они выглядят отшлифованными и приходят быстро. Цена проявляется позже: больше мест для скрытия багов, больше файлов для просмотра и больше моментов «что это вообще делает?».

Когда код дешёв, сложность — это то, за что вы платите. Небольшой, скучный дизайн проще тестировать, проще менять и проще объяснить. Это особенно важно, когда первый набросок пришёл от модели, которая может уверенно звучать, оставаясь тонко неверной.

Практическое правило — держать функции, компоненты и модули настолько небольшими, чтобы коллега мог просмотреть их за несколько минут, а не часов. Если React‑компонент требует нескольких кастомных хуков, локальной машины состояний и слоя «умного рендера», остановитесь и спросите: решаем ли мы реальную проблему или просто принимаем архитектуру, потому что ИИ её предложил?

Несколько «тестов простоты» помогут вам сопротивляться:

• Поймёт ли новый коллега основной поток за один присест?
• Смогли бы вы удалить эту абстракцию и заменить её явным кодом без потери ясности?
• Есть ли одно очевидное место, чтобы исправить баг, или пять?
• Имеет ли каждая часть одну задачу, которую можно сформулировать в одном предложении?

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

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

Если вы работаете в чат‑инструменте вроде Koder.ai, простота также делает снимки и откат более ценными. Небольшие очевидные изменения проще сравнить, сохранить или вернуть назад.

Найм: вам нужны редакторы и принимающие решения, а не наборщики кода

Когда код легко генерировать, дефицит навыка — в умении выбирать, что вообще должно существовать, и следить, чтобы это было корректно. Старый совет «нанимайте отличных программистов» остаётся в силе, но роль смещается. Вы нанимаете не для того, чтобы кто‑то печатал быстрее. Вы нанимаете того, кто может судить, дорабатывать и защищать продукт.

Самые ценные люди в разработке с поддержкой ИИ обычно обладают четырьмя чертами: суждение (что важно), вкус (что хорошо), навык отладки (нахождение корня проблемы) и коммуникация (ясное объяснение компромиссов). Они могут взять фичу, написанную ИИ, которая «в целом работает», и превратить её в то, чему можно доверять.

Лучшее интервью: улучшить изменение от ИИ

Вместо того чтобы просить идеальное решение с нуля, дайте кандидату pull request, сгенеренный ИИ (или вставленный diff) с несколькими реалистичными проблемами: неясные имена, скрытый краевой случай, отсутствующие тесты и небольшая ошибка безопасности.

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

Это покажет, как они думают в реальных условиях: с несовершенным кодом, ограниченным временем и необходимостью выбирать приоритеты.

Суперсила: уметь сказать «нет»

ИИ часто звучит уверенно. Хорошие сотрудники умеют возражать. Они способны сказать «нет» фиче, которая добавляет сложность, «нет» изменению, которое ослабляет безопасность, и «нет» отправке без доказательств.

Конкретный сигнал — как они отвечают на «Смерджишь это?» Сильные кандидаты не дают ощущения; они дают решение и короткий список необходимых изменений.

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

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

Спеки и планирование: более ясные промпты начинаются с более ясного мышления

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

Хороший промпт обычно — это короткая спецификация в маскировке. Прежде чем просить код, превратите размытое желание в несколько критериев приёмки и явных не‑целей. Это предотвращает тихое расширение области задач моделью (и командой).

Держите спецификацию маленькой, но точной. Вы не пишете роман. Вы задаёте границы вокруг:

• Входов: что приходит (поля, форматы, крайние случаи)
• Выходов: что должно выходить (с примерами)
• Ошибок: что может пойти не так и как на это реагировать
• Ограничений: производительность, приватность, зависимости или области, которые нельзя менять
• Не‑целей: что вы не делаете в этом изменении

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

Пример: вы хотите «добавить сброс пароля». Чёткая спецификация могла бы сказать: пользователь запрашивает сброс по email; ссылки истекают через 15 минут; сообщение одно и то же, есть ли email в базе или нет; лимит запросов на IP; логируем попытки сброса без хранения токенов в открытом виде. Не‑цель: редизайн страницы логина. Теперь ваш промпт имеет ограждения и ревью становятся проще.

Ведите лёгкий журнал изменений решений. Один абзац на решение достаточно. Запишите, почему вы выбрали подход и почему отклонили альтернативы. Когда через две недели кто‑то спросит «почему так?», у вас будет ответ.

Практический рабочий цикл с ИИ, который можно повторять

Самое большое изменение с ИИ — код производить легко. Сложная часть — решить, что код должен делать, и доказать, что он это делает.

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

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

Повторяемая петля выглядит так:

1. Напишите короткое описание проблемы и 3–5 чётких критериев приёмки «пройден/не пройден».
2. Попросите минимальный план: модель данных, ключевые функции и что может пойти не так.
3. Генерируйте одно небольшое изменение за раз (один эндпоинт, один UI‑экран, одна миграция), не весь дамп приложения.
4. Ревью как редактор: читайте диффы, запускайте тесты, пробуйте случаи отказа, затем просите исправления.
5. Безопасный релиз: используйте флаг или ограниченный релиз, смотрите логи и метрики и будьте готовы откатиться.

Вот небольшой сценарий: вы добавляете «статус возврата» на экран заказа. ИИ быстро генерирует UI, но корректность живёт в краевых случаях. Что если возврат частичный? Что если платёжный провайдер повторно шлёт webhook? Сначала опишите эти кейсы, затем реализуйте одну часть (столбец в БД плюс валидация) и проверьте её тестами перед тем, как двигаться дальше.

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

Распространённые ошибки, когда код от ИИ кажется слишком простым

Когда генерация кода быстрая, легко начать думать, что продукт — это сам код. Это не так. Продукт — это поведение: приложение делает то, что нужно, даже когда что‑то идёт не так.

1) Верить уверенной выдаче без доказательств

ИИ часто звучит уверенно, даже когда догадывается. Ошибка — пропустить скучную часть: запуск тестов, проверку краёв и валидацию реальных вводов.

Простая привычка помогает: прежде чем принять изменение, спросите «Как мы узнаем, что это правильно?» Если ответ «похоже правильно», вы играете в азартную игру.

2) Давать инструменту разрастаться в объёмах задач

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

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

3) Мержить слишком большие изменения, чтобы их можно было ревьюить

Большой коммит от ИИ может скрывать дюжину несвязанных решений. Ревью превращается в формальность, потому что никто не может охватить всё.

Обращайтесь к выводу чата как к черновику. Разбивайте его на маленькие изменения, которые можно прочитать, запустить и откатить. Снимки и откат полезны только если вы делаете их в разумных точках.

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

4) Копировать код с неясной лицензией или риском безопасности

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

Если вы не можете объяснить, что делает фрагмент, не шипуйте его. Попросите более простой вариант или перепишите сами.

5) Забывать про миграции, масштабы и режимы отказа

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

Реалистичный пример: модель добавляет NOT NULL‑столбец в PostgreSQL и заполняет его медленным бэкфиллом. В продакшене это может заблокировать таблицу и сломать приложение. Всегда думайте, что произойдёт с миллионом строк, с медленной сетью или с неудачным деплоем посередине.