«Важно доставлять, а не понимать» — идеальный способ работы с нейросетями

«Важно доставлять, а не понимать» — звучит модно, а ломает всё по классике.

Последние месяцы я вижу одну и ту же сцену.

Кто-то начинает активно применять нейросети в разработке — и первые недели ощущение кайфовое:
код появляется быстрее, задач закрывается больше, “как будто полетели”.

А потом начинаются знакомые фразы:

• “стало больше багов, хотя писали быстрее”

• “вроде всё правильно, но не работает”

• “оно компилируется, значит норм”

• “главное — доставлять, а не понимать”

Вот с последним тезисом я не согласен.

Доставлять то, что ты не понимаешь и не проверил — это не доставка.
Это перенос неопределённости в прод. А прод обычно голосует не лайками.

Где именно всё ломается

Нейросети идеально умеют одно: генерировать.

Но есть две вещи, которые они за нас не делают:

1. Проверка (интеграции, крайние случаи, регрессии, контракты).

2. Ответственность (кто будет разгребать последствия — всегда человек).

Если проверок и контроля изменений нет — ИИ просто ускоряет поток изменений, а вместе с ним ускоряет и поток ошибок.

Самая короткая формула, которая объясняет 80% треша

ИИ увеличивает throughput — скорость генерации и поток изменений.

Но если нет гейтов, он увеличивает и variance — разброс и случайности ^[1].

Проще: скорость ↑, неопределённость ↑.
А дальше всё по учебнику: ошибка ^[2] не исчезает — она просто “переезжает” ближе к продакшену.

Красные флаги (если узнал себя — нормально, мы все там были)

• “потом тесты”

• “вроде ок”

• “модель сказала”

• “не понимаю, но компилится”

• “потом пруф”

• “быстро в прод”

Эти фразы сами по себе не “зло”. Зло — когда это становится процессом по умолчанию.

Что реально работает (скучно — значит эффективно)

Рабочий способ почти всегда один:

Один инструмент → один сценарий → один пруф.

Не “зоопарк инструментов”, не “агенты на все случаи”, не “подписки на всё подряд”.
А маленькая дисциплина:

1. Один маленький кусок (одна функция / один эндпойнт / одна миграция).

2. Одна проверка (smoke / минимальный тест / preflight — хоть что-то, но повторяемое).

3. Одна фиксация результата (evidence — чтобы через неделю не угадывать, что было сделано).

4. Только потом следующий шаг и расширение.

Протокол “Пруф” (минимальный, но взрослый)

Мой минимальный “гейт”, после которого я считаю, что это реально можно доставлять:

Пруф = Diff + Check + Evidence

• Diff: что поменяли (объём ограничен, изменения понятны)

• Check: чем проверили (smoke/тест/контракт)

• Evidence: что получилось (логи/артефакты/сводка)

Это не бюрократия. Это способ сделать так, чтобы спорить с реальностью стало сложно.

Как начать без “зоопарка” (быстро и спокойно)

Если сейчас хочется “войти в ИИ”, но страшно деградировать качество, то старт простой:

• выбери один самый частый сценарий (где реально болит)

• сделай один повторяемый smoke/preflight

• заведи одну папку evidence

• ограничь изменения до “одного маленького куска”

И только когда это стабильно даёт пользу — добавляй второй сценарий / второй инструмент.

Подписки не покупают дисциплину. Дисциплина покупает результат.

Вывод

ИИ — это реально мощно. Но это усилитель процесса, а не замена процесса.

• Нет процесса → ИИ усилит хаос.

• Есть процесс → ИИ даст честный буст скорости и качества.

Вопрос в зал (хочу реальные кейсы)

1. Что у вас чаще всего ломается с нейросетями: контекст, интеграции, тесты, контроль изменений?

2. Был ли “самый дорогой баг из-за ИИ”? На каком шаге он должен был быть пойман?

3. Какие правила/гейты у вас реально работают, чтобы нейросети ускоряли, а не деградировали?