забрал у Григория Добрякова:

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

Блять. Как бы вам это сказать, ребятки.

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

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

Во многих компаниях я участвовал во встречах с C-level как представитель разработки. На таких встречах инженерная работа обсуждается через стоимость, сроки и риски. Разработку воспринимают как затратный центр, который нужно оптимизировать.

В обсуждениях — бюджет, ROI и задержки. Один раунд багфиксинга после релиза — и финансовый директор считает убытки не по часам разработчиков, а по потерянным продажам, оттоку клиентов и импотентскому time-to-market.

Просто вам это не говорят, чтоб вы не уволились нахер с тоски.

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

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

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

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

Вчерашний архитектор садится на совещание с VP и CEO — и вдруг понимает: всё, во что он верил, здесь не стоит ничего. Здесь считают, сколько стоит задержка фичи в деньгах, сколько клиентов потеряли за квартал из-за бага в проде, и на сколько процентов можно сократить engineering headcount, если перенести часть задач на AI.

Чтобы не быть голословным — вот как это работает на практике.

В одной компании AI-внедрение в этом случае шло сверху: решение принял менеджмент. За 6–8 месяцев выделился отдельный AI-департамент. Нетехнические сотрудники — маркетологи, аналитики, операционщики — сами начали собирать себе инструменты. Не потому что заставили, а потому что наконец-то появилась возможность получить результат, не дожидаясь очереди в JIRA.

AI-бот к data lake сократил типовой запрос к данным с нескольких дней ожидания до секунд в простых случаях. Буквально вопрос и ответ вместо заявки, приоритизации, ожидания и отчёта.

В другом SaaS-продукте в трекере были тысячи багов и ежедневно появлялось ещё 5–10. Релизы раз в несколько месяцев. Клиенты боялись обновляться, потому что после каждого обновления что-нибудь ломалось. Стандартная реальность, к которой бизнес привык и перестал ожидать другого.

И вот в этом контексте появляется AI-assisted разработка, которая сократила часть типовых задач от недель до 10–30 минут. Выводы?