«Суждение о результате обязано оставаться за человеком». Да ну? Или вы просто кресло греете?

«Обязано» — не закон природы, а защита уютного кресла. Граница делегируемого суждения подвижна, а model-as-a-judge — рабочая практика.

Есть фраза, которую произносят с таким лицом, будто цитируют закон сохранения энергии:

— ИИ может быть отличным исполнителем, но суждение о результате должно оставаться за человеком!

Красиво. Уверенно. И всё время хочется спросить одно: а почему, собственно, ДОЛЖНО?

Не «удобно ли», не «привычно ли», не «страшно ли отпустить» — а именно это железобетонное «обязано». Кто выдал обязанность? Где она записана? Звучит не как вывод из практики, а как установка, которую очень не хочется проверять.

Continue reading “«Суждение о результате обязано оставаться за человеком». Да ну? Или вы просто кресло греете?”

Отойдите от меня со своей линейкой

Экспертный перфекционизм — это не забота о качестве, а посттравматическая роль училки с линейкой. Заказчик выбирает ИИ не потому что тот умнее, а потому что тот не усаживает его за парту.


# Отойдите от меня со своей линейкой

— Неспециалист просто не видит косяки! — орут они мне хором. — Вот мы, настоящие специалисты, косяки видим! Поэтому только мы должны решать задачи, а не какой-то гуманитарий с ИИ в руках!

Погроммисты говорят: заказчик просто не видит косяков в коде.

Дизайнеры говорят: заказчик просто не видит косяков в дизайне.

Сценаристы говорят: заказчик просто не видит косяков в тексте.

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

<!--more-->

Но в этом споре речь не только о качестве. В этом хоре «мы видим, а ты нет» виден школьный рефлекс контроля.

## Училка ходит между рядами парт

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

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

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

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

## Заказчик просит только одного

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

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

Разницу можно проверить по последствиям для задачи, потому что цена у них разная. Забота стоит заказчику решённой задачи. Линейка стоит ему потерянного времени, испорченного настроения и ощущения, что его снова, как в шестом классе, поймали на «неправильном отступе» — только теперь за его же деньги.

## Ссылка на идеальный результат иногда прикрывает желание контролировать процесс

Потому что об идеальном результате вы рассуждаете не с целью помочь, а с целью показать себя. Это считывается по тону общения — будь вы сценарист, дизайнер или разработчик.

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

Рабочий критерий такой: забота о качестве начинается с вопроса «а тебе это вообще нужно для твоей задачи?». Линейка этого вопроса не задаёт никогда — ей важно не чтобы стало лучше, а чтобы стало по её лекалу. Помощь соотносит правку с задачей; контроль требует соответствия собственному стандарту.

## В рабочих отношениях без школьной иерархии ошибки разбирают иначе

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

Никому из предпринимателей не придёт в голову гнобить «коллегу» за то, что у того в продукте код написан не по паттернам. Там ошибка — это часть движения, а не приговор, за который отправляют переписывать домашку. Взрослые рабочие отношения строятся не на наказании за каждую ошибку. Линейка живёт только там, где кто-то так и не вышел из-за той самой парты.

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

## Он просто не усаживает за парту

Для специалистов неприятно другое: заказчик выбирает ИИ не потому, что тот умнее специалиста. Часто он и не умнее. Заказчик выбирает его потому, что тот не пытается усадить его за парту.

ИИ не сопровождает задачу оценочными комментариями и статусным давлением. Он берёт задачу — и делает её более-менее так, как ты просил. Ровно то, о чём заказчик и просил живых людей, а в ответ получал менторский тон.

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

## Куда бить линейкой теперь

Практический вывод такой:

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

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

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

Чистый код был налогом. Просто платили его собой

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

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

Continue reading “Чистый код был налогом. Просто платили его собой”

«Свалим всё в один репозиторий — агенту так удобнее»: вы сломали архитектуру ради фокуса, который вам померещился

Монорепа ради агента — карго-культ. Модели всё равно, откуда физически читается файл: tool_use уже развязал источник контента и способ его подачи.

Наткнулся на один AI-психоз под страшным названием «монорепа». Люди на полном серьёзе складывают разные проекты физически в один git-репозиторий — потому что им кажется, что так агенту проще «ходить по файлам» и понимать общий контекст большой корпоративной системы. И под постом десятки комментариев: о да, мы теперь тоже стали так делать, отличный механизм, все довольны.

Блять, люди, вы ёбанулись совсем?

Continue reading “«Свалим всё в один репозиторий — агенту так удобнее»: вы сломали архитектуру ради фокуса, который вам померещился”

Зачем документация, если агент читает код напрямую

Контекстное окно на два миллиона токенов — не повод хоронить документацию. Без спецификации агент не отличит фичу от бага и запечатает ошибку тестом.

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

Код фиксирует текущую реализацию, но не фиксирует исходное намерение и бизнес-ограничения. Он содержит текущую реализацию, включая исторические компромиссы, баги и устаревшие решения. А это разные вещи.

Continue reading “Зачем документация, если агент читает код напрямую”

AI-Driven Head of Engineering: что предъявить HR и нанимающему менеджеру

Банк прямых ответов на восемь групп вопросов, которые HR и hiring manager задают профилю AI-Driven Head of Engineering — от подлинности и hands-on до governance, ROI и логистики.

В найме AI-лидеров часто путают опыт внедрения с умением говорить об AI: часть кандидатов показывает презентации и стратегию, но не показывает работающие системы, код или продовые внедрения. Нанимающий менеджер это понимает и проверяет артефакты: работающие сервисы, репозитории, продовые метрики, ownership — по ссылкам на системы, коду, метрикам и описанным решениям. Ниже — прямые ответы на восемь групп вопросов, которые HR и hiring manager задают профилю AI-Driven Head of Engineering. По каждой теме: что сделано, чем подтверждается, где есть ограничения.

Continue reading “AI-Driven Head of Engineering: что предъявить HR и нанимающему менеджеру”

Эпоха алгоритмического управления: конец «незаменимых» менеджеров

Первая волна ИИ обесценила труд исполнителей. Вторая идёт за теми, кто распределял их задачи — и защищает ренту за визирование.

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

Continue reading “Эпоха алгоритмического управления: конец «незаменимых» менеджеров”

AI на каждой фазе SDLC: практики, пруфы, цифры

Доказательное применение AI на всех этапах жизненного цикла разработки ПО — от сбора требований до мониторинга в production. Практики, коммерческий контекст, цифры результата и публичные артефакты.

Стандартный вопрос найма: AI у всех пишет код — покажите, что вы применяли его на каждой фазе SDLC, а не только в IDE. Ниже — список практик по фазам SDLC с артефактами. Разбор сгруппирован по Planning, Requirements, Design, Implementation, Testing, Deployment, Maintenance и отдельному блоку delivery management. Для каждой фазы — конкретная практика, коммерческий контекст, цифры результата и публичный артефакт, который можно проверить по ссылке или репозиторию.

Continue reading “AI на каждой фазе SDLC: практики, пруфы, цифры”

Вот зачем AI-агенту таск-менеджер

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

— Лол, зачем AI-агенту вообще инструмент для управления проектом? Он же просто берёт и делает! — написали мне десятки человек.

Признаюсь, именно на этом я и хотел вас подловить.

Continue reading “Вот зачем AI-агенту таск-менеджер”

Падение прода — это рутина, а не апокалипсис

Разбираем угрозу «вот упадёт ваш вайб-кодинг в проде — и тогда». Что именно «тогда» — по слоям: ентерпрайз, малый бизнес, продвинутый одиночка с ИИ.

Каждый пост про ИИ магнитом притягивает десятки странных чуваков с одной и той же мыслью: вот однажды ваше навайбкоженное упадёт в проде — и тогда…

Continue reading “Падение прода — это рутина, а не апокалипсис”