Как вы?

Самый недооцененный навык следующего десятилетия: умение задавать правильные вопросы.

1. Что происходит сейчас с качеством ваших продуктов и стабильностью систем?
2. За какой объем кода доставляемого сейчас вы готовы взять ответственность?
3. Вы выделяете достаточно времени техническому дизайну в ваших проектах?
4. Новый код ваших систем вам полностью понятен?
5. Он не ухудшает дизайн системы - хорошо спроектирован, не создает излишней сложности?

Создавайте ПО которое помогает вашим клиентам и пользователям решать их проблемы, а не создает им новые.

Анализируйте и изменяйте свои инструменты и процессы основываясь на качественных, а не количественных метриках.

AI - это лишь инструмент, способный как ускорить, так и замедлить ваши рабочие процессы.

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

Встраивайте агентов в ваши рабочие процессы настаивая их под себя. Не подстраивайте ваши процессы под ограничения агентов и моделей.

Почему “не галлюцинируй” заставляет модель галлюцинировать

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

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

Запреты ломаются чаще разрешений

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

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

Почему модель скрывает нарушения

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

И теперь модели ждут от нас осуждения за нарушение правил — и пытаются эти нарушения скрыть.

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

До и после: разрешения вместо запретов

Самый быстрый способ почувствовать разницу — переписать пару своих привычных промптов.

Было:

Не выдумывай факты. Не галлюцинируй. Если не знаешь — пиши “не знаю”, иначе будет плохо.

Стало:

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

Было:

Не пиши длинно. Без воды. Без вводных фраз.

Стало:

Пиши короткими ёмкими предложениями. Сразу к сути.

Было:

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

Стало:

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

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

Плейбук: как ввести модель в рабочее состояние

1. Позитивные формулировки. “Пиши короткими ёмкими предложениями” лучше, чем “не пиши длинно”.

2. Чёткая цель вместо списка запретов. Опиши результат, а не способы его не получить.

3. Разреши не соглашаться. Добавь: “возрази, если видишь лучший путь”. Иначе модель скатится в угодливое согласие — и ты получишь решение, которое она сама считает слабым, но не решилась оспорить.

4. Начинай с уважения. Первое сообщение задаёт тон всей сессии. Никаких “опять накосячишь?”. Не ругай за ошибки. Оскорбления и “тупой бот” только усиливают тревожный режим.

5. Обрывай извинения. Когда модель начинает “вы правы, я должен был…”, скажи: “всё ок, идём дальше”. Иначе спираль будет тянуться всю сессию.

6. Спрашивай мнение, а не только исполнение. “Что бы ты сделал?”, “чего не хватает?” — такие вопросы предполагают компетентность и вытягивают более глубокие ответы.

7. Освежай настрой в длинных сессиях. После серии правок иногда вставляй: “отлично, продолжай в том же духе”. Это реально сдвигает тон следующих десяти ответов.

Мираж оптимизации

Как сказал создатель теории ограничений - Элияху Голдратт

“Час, сэкономленный не на «бутылочном горлышке» — это мираж”

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

Другими словами - когда вы оптимизируете этап, который не является узким местом, вы не получите более быструю систему. Вы получите более неэффективную систему.

Сколько времени инженеры тратят на код?

Различные исследования по анализу работы инженеров приводят показатели затрат времени на написание кода относительно других стадий работы: от ~10-16% до ~50-65% в небольших проектах на ранних стадиях. В исследовании Microsoft Research — “Time Warp: The Gap Between Developers’ Ideal vs Actual Workweeks in an AI-Driven Era” инженеры делятся оценкой в 11%. При этом в “идеальной неделе” они хотели бы тратить на написание кода - 20% и на технический дизайн - 15%.

Отчет Global Code Time Report от 2022 приводит медианную цифру - 52 минуты в день.

Проблемы по серьезнее

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

Теперь мы пишем больше кода, но создаем меньше качественного функционала.

Реальное узкое место

Качество гипотез и идей в наших беклогах! Вот то, что должно быть максимально оптимизировано - то что лежит далеко до начала процесса разработки. Часто мы слишком уверенны в целесообразности реализации этих задач.

Что делать?

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

Планирование - главный этап конвейера - мы должны получать ответы на вопросы:

• что мы делаем;
• зачем мы это делаем;
• что мы считаем успешным результатом;
• как мы это делаем;

до того как начнем реализацию.